linux-kernel - Re: [PATCH v2 02/21] rcu: Re-implement RCU Tasks Trace in terms of SRCU-fast

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: <aOUDQeLtfeoBEPng@localhost.localdomain>
Date: Tue, 7 Oct 2025 14:10:41 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: rcu@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-team@...a.com,
	rostedt@...dmis.org, kernel test robot <oliver.sang@...el.com>,
	Andrii Nakryiko <andrii@...nel.org>,
	Alexei Starovoitov <ast@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>, bpf@...r.kernel.org
Subject: Re: [PATCH v2 02/21] rcu: Re-implement RCU Tasks Trace in terms of
 SRCU-fast

Le Sat, Oct 04, 2025 at 02:47:08AM -0700, Paul E. McKenney a écrit :
> On Thu, Oct 02, 2025 at 05:46:10PM +0200, Frederic Weisbecker wrote:
> > Le Wed, Oct 01, 2025 at 07:48:13AM -0700, Paul E. McKenney a écrit :
> > > This commit saves more than 500 lines of RCU code by re-implementing
> > > RCU Tasks Trace in terms of SRCU-fast.  Follow-up work will remove
> > > more code that does not cause problems by its presence, but that is no
> > > longer required.
> > > 
> > > This variant places smp_mb() in rcu_read_{,un}lock_trace(), which will
> > > be removed on common-case architectures in a later commit.
> > 
> > The changelog doesn't mention what this is ordering :-)
> 
> "The ordering that dare not be named"?  ;-)
> 
> How about like this for that second paragraph?
> 
> 	This variant places smp_mb() in rcu_read_{,un}lock_trace(),
> 	which will be removed on common-case architectures in a
> 	later commit.  In the meantime, it serves to enforce ordering
> 	between the underlying srcu_read_{,un}lock_fast() markers and
> 	the intervening critical section, even on architectures that
> 	permit attaching tracepoints on regions of code not watched
> 	by RCU.  Such architectures defeat SRCU-fast's use of implicit
> 	single-instruction, interrupts-disabled, and atomic-operation
> 	RCU read-side critical sections, which have no effect when RCU is
> 	not watching.  The aforementioned later commit will insert these
> 	smp_mb() calls only on architectures that have not used noinstr to
> 	prevent attaching tracepoints to code where RCU is not watching.

Oh I see now. So basically this forces the SRCU-slow behaviour by
restoring the full barriers that are within SRCU-slow's srcu_read_[un]lock()
(can we add a word about that?) for those architectures due to unwatched
RCU sections that can escape the vigilance of the synchronize_rcu() on
the write side.

Thanks.

-- 
Frederic Weisbecker
SUSE Labs