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
