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
