[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250911192040.6c5ccb51@gandalf.local.home>
Date: Thu, 11 Sep 2025 19:20:40 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: Steven Rostedt <rostedt@...nel.org>, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, Masami Hiramatsu <mhiramat@...nel.org>,
Mark Rutland <mark.rutland@....com>, Mathieu Desnoyers
<mathieu.desnoyers@...icios.com>, Andrew Morton
<akpm@...ux-foundation.org>, Peter Zijlstra <peterz@...radead.org>,
Namhyung Kim <namhyung@...nel.org>, Takaya Saeki <takayas@...gle.com>, Tom
Zanussi <zanussi@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Ian
Rogers <irogers@...gle.com>, aahringo@...hat.com, Douglas Raillard
<douglas.raillard@....com>
Subject: Re: [PATCH 1/7] tracing: Replace syscall RCU pointer assignment
with READ/WRITE_ONCE()
Finally have time to get back to these patches.
On Wed, 6 Aug 2025 11:39:57 -0700
"Paul E. McKenney" <paulmck@...nel.org> wrote:
> On Tue, Aug 05, 2025 at 03:26:47PM -0400, Steven Rostedt wrote:
> > From: Steven Rostedt <rostedt@...dmis.org>
> >
> > The syscall events are pseudo events that hook to the raw syscalls. The
> > ftrace_syscall_enter/exit() callback is called by the raw_syscall
> > enter/exit tracepoints respectively whenever any of the syscall events are
> > enabled.
> >
> > The trace_array has an array of syscall "files" that correspond to the
> > system calls based on their __NR_SYSCALL number. The array is read and if
> > there's a pointer to a trace_event_file then it is considered enabled and
> > if it is NULL that syscall event is considered disabled.
> >
> > Currently it uses an rcu_dereference_sched() to get this pointer and a
> > rcu_assign_ptr() or RCU_INIT_POINTER() to write to it. This is unnecessary
> > as the file pointer will not go away outside the synchronization of the
> > tracepoint logic itself. And this code adds no extra RCU synchronization
> > that uses this.
> >
> > Replace these functions with a simple READ_ONCE() and WRITE_ONCE() which
> > is all they need. This will also allow this code to not depend on
> > preemption being disabled as system call tracepoints are now allowed to
> > fault.
> >
> > Cc: "Paul E. McKenney" <paulmck@...nel.org>
> > Signed-off-by: Steven Rostedt (Google) <rostedt@...dmis.org>
>
> >From an RCU-removal viewpoint:
>
> Reviewed-by: Paul E. McKenney <paulmck@...nel.org>
Thanks for the review. I'm also removing the __rcu that triggered the bot.
>
> But is it possible to give some sort of warning just in case some creative
> future developer figures out how to make the file pointer go away outside
> of the synchronization of the tracepoint logic itself?
That would be quite a big change, and since this is the core code to it,
that future change should fix up this code as well. All the modification
happens in this file so nothing should be hidden.
If they do get it wrong, it should crash pretty amazingly if there's any
testing ;-)
-- Steve
Powered by blists - more mailing lists