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: <20251114171052.gJRc-2A3@linutronix.de>
Date: Fri, 14 Nov 2025 18:10:52 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
	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>,
	yonghong.song@...ux.dev
Subject: Re: linux-next: manual merge of the rcu tree with the ftrace tree

On 2025-11-14 09:00:21 [-0800], Paul E. McKenney wrote:
> > > Where in PREEMPT_RT we do not disable preemption around the tracepoint
> > > callback, but in non RT we do. Instead it uses a srcu and migrate disable.
> > 
> > I appreciate the effort. I really do. But why can't we have SRCU on both
> > configs?
> 
> Due to performance concerns for non-RT kernels and workloads, where we
> really need preemption disabled.

This means srcu_read_lock_notrace() is much more overhead compared to
rcu_read_lock_sched_notrace()?
I am a bit afraid of different bugs here and there.

> > Also why does tracepoint_guard() need to disable migration? The BPF
> > program already disables migrations (see for instance
> > bpf_prog_run_array()).
> > This is true for RT and !RT. So there is no need to do it here.
> 
> The addition of migration disabling was in response to failures, which
> this fixed.  Or at least greatly reduced the probability of!  Let's see...
> That migrate_disable() has been there since 2022, so the failures were
> happening despite it.  Adding Yonghong on CC for his perspective.

Okay. In general I would prefer that we know why we do it. BPF had
preempt_disable() which was turned into migrate_disable() for RT reasons
since remaining on the same CPU was enough and preempt_disable() was the
only way to enforce it at the time.
And I think Linus requested migrate_disable() to work regardless of RT
which PeterZ made happen (for different reasons, not BPF related).

> 							Thanx, Paul

Sebastian