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

[Frederic Weisbecker <frederic@kernel.org>]

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@canb.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?

Thanks.

-- 
Frederic Weisbecker
SUSE Labs