[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e2674451-21f2-4388-bf3c-8ca9946f81cf@paulmck-laptop>
Date: Fri, 14 Nov 2025 09:05:49 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
Frederic Weisbecker <frederic@...nel.org>,
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>,
yonghong.song@...ux.dev
Subject: Re: linux-next: manual merge of the rcu tree with the ftrace tree
On Fri, Nov 14, 2025 at 07:42:55AM -0500, Steven Rostedt wrote:
> 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?
I could, but I believe that this would re-introduce the migration failure.
Maybe we should just defer this until both your patch and the RCU
stack hit mainline, and port on top of those? Perhaps later in the
merge window?
I believe that migration needs to be disabled at this point, but I am
again adding Yonghong on CC for his perspective.
Thanx, Paul
> Thanks,
>
> -- Steve
>
>
> >
> > syscall_nr = trace_get_syscall_nr(current, regs);
> > if (syscall_nr < 0 || syscall_nr >= NR_syscalls)
Powered by blists - more mailing lists