linux-kernel - Re: linux-next: manual merge of the rcu tree with the ftrace tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f79a2e18-d9c3-40db-97ed-c334b90cf3ba@paulmck-laptop>
Date: Tue, 18 Nov 2025 07:04:07 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
	Boqun Feng <boqun.feng@...il.com>,
	Uladzislau Rezki <urezki@...il.com>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Next Mailing List <linux-next@...r.kernel.org>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: Re: linux-next: manual merge of the rcu tree with the ftrace tree

On Tue, Nov 18, 2025 at 02:05:03PM +0100, Frederic Weisbecker wrote:
> Le Fri, Nov 14, 2025 at 09:06:29AM -0800, Paul E. McKenney a écrit :
> > On Fri, Nov 14, 2025 at 03:48:52PM +0100, Frederic Weisbecker wrote:
> > > Le Fri, Nov 14, 2025 at 07:42:55AM -0500, Steven Rostedt a écrit :
> > > > On Fri, 14 Nov 2025 13:52:26 +1100
> > > > Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> > > > 
> > > > > Hi all,
> > > > > 
> > > > > Today's linux-next merge of the rcu tree got a conflict in:
> > > > > 
> > > > >   kernel/trace/trace_syscalls.c
> > > > > 
> > > > > between commit:
> > > > > 
> > > > >   a544d9a66bdf ("tracing: Have syscall trace events read user space string")
> > > > > 
> > > > > from the ftrace tree and commit:
> > > > > 
> > > > >   35587dbc58dd ("tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast")
> > > > > 
> > > > > from the rcu tree.
> > > > > 
> > > > > I fixed it up (Maybe - see below) and can carry the fix as necessary. This
> > > > > is now fixed as far as linux-next is concerned, but any non trivial
> > > > > conflicts should be mentioned to your upstream maintainer when your tree
> > > > > is submitted for merging.  You may also want to consider cooperating
> > > > > with the maintainer of the conflicting tree to minimise any particularly
> > > > > complex conflicts.
> > > > 
> > > > Thanks for the update.
> > > > 
> > > > > 
> > > > 
> > > > > diff --cc kernel/trace/trace_syscalls.c
> > > > > index e96d0063cbcf,3f699b198c56..000000000000
> > > > > --- a/kernel/trace/trace_syscalls.c
> > > > > +++ b/kernel/trace/trace_syscalls.c
> > > > > @@@ -878,6 -322,8 +890,7 @@@ static void ftrace_syscall_enter(void *
> > > > >   	 * buffer and per-cpu data require preemption to be disabled.
> > > > >   	 */
> > > > >   	might_fault();
> > > > > + 	preempt_rt_guard();
> > > > >  -	guard(preempt_notrace)();
> > > > 
> > > > My code made it so that preemption is not needed here but is moved later
> > > > down for the logic that does the reading of user space data.
> > > > 
> > > > Note, it must have preemption disabled for all configs (including RT).
> > > > Otherwise, the data it has can get corrupted.
> > > > 
> > > > Paul, can you change it so that you *do not* touch this file?
> > > 
> > > Ok, I've zapped the commit for now until we sort this out.
> > 
> > Thank you, Frederic, and I guess putting this in -next did indeed find
> > some problems, so that is good?  ;-)
> 
> Indeed, mission accomplished ;-)
> 
> Steve proposed here to actually restore the patch:
> 
>     https://lore.kernel.org/lkml/20251114110136.3d36deca@gandalf.local.home/
> 
> But later said the reverse:
> 
>     https://lore.kernel.org/lkml/20251114121141.5e40428d@gandalf.local.home/
> 
> So for now I'm still keeping it outside -next. I hope it is not a necessary
> change in your srcu series?

My thought is to put the patch with Steven's suggested removal on my
-rcu stack and see what kernel test robot thinks of it.  ;-)

							Thanx, Paul