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: <20251114121141.5e40428d@gandalf.local.home>
Date: Fri, 14 Nov 2025 12:11:41 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Stephen
 Rothwell <sfr@...b.auug.org.au>, "Paul E. McKenney" <paulmck@...nel.org>,
 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
 Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the rcu tree with the ftrace tree

On Fri, 14 Nov 2025 18:02:32 +0100
Sebastian Andrzej Siewior <bigeasy@...utronix.de> wrote:

> > I don't know. Is there more overhead with disabling migration than
> > disabling preemption?  
> 
> On the first and last invocation, yes. But we if disabling migration is
> not required for SRCU then why doing it?

I'll yield to the BPF experts here.

> > 
> > We also would need to audit all tracepoint callbacks, as there may be some
> > assumptions about staying on the same CPU.  
> 
> Sure. Okay. What would I need to grep for in order to audit it?

Probably anything that uses per-cpu or smp_processor_id().

> > void *trace_event_buffer_reserve(struct trace_event_buffer *fbuffer,
> > 				 struct trace_event_file *trace_file,
> > 				 unsigned long len)
> > {
> > 	return event_buffer_reserve(fbuffer, trace_file, len, true);
> > }
> > 
> > void *trace_syscall_event_buffer_reserve(struct trace_event_buffer *fbuffer,
> > 					 struct trace_event_file *trace_file,
> > 					 unsigned long len)
> > {
> > 	return event_buffer_reserve(fbuffer, trace_file, len, false);
> > }
> > 
> > Hmm  
> 
> Yeah. I *think* in the preempt case we always use the one or the other.

OK, we can do this instead. Probably cleaner anyway.

> 
> So I would prefer this instead of explicitly disable migration so the a
> function down in the stack can decrement the counter again.
> Ideally, we don't disable migration to begin with.
> 
> _If_ the BPF program disables migrations before invocation of its
> program then any trace recording that happens within this program
> _should_ record the migration counter at that time. Which would be 1 at
> the minimum.

Again, I yield to the BPF folks.

Frederic, it may be good to zap this patch from your repo. It looks like it
still needs more work.

Thanks,

-- Steve