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" [off-list ref] wrote:

On Tue, Aug 05, 2025 at 03:26:47PM -0400, Steven Rostedt wrote:

quoted

From: Steven Rostedt <rostedt@goodmis.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@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>  

quoted

From an RCU-removal viewpoint:  

Reviewed-by: Paul E. McKenney <paulmck@kernel.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