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] [day] [month] [year] [list]

Message-ID: <79baf0a4-dae2-4748-a1a8-112ce1d5fa94@paulmck-laptop>
Date: Tue, 7 Oct 2025 06:47:29 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Frederic Weisbecker <frederic@...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

On Tue, Oct 07, 2025 at 02:10:41PM +0200, Frederic Weisbecker wrote:
> 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.

You got it!  I will add the connection to old-school srcu_read_[un]lock()
on my next rebase.

							Thanx, Paul

> Thanks.
> 
> -- 
> Frederic Weisbecker
> SUSE Labs