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

[Frederic Weisbecker <frederic@kernel.org>]

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