On Wed, Mar 19, 2025 at 10:01:36AM +0100, Frederic Weisbecker wrote:
> Le Tue, Mar 18, 2025 at 10:18:12AM -0700, Paul E. McKenney a écrit :
> > On Fri, Mar 14, 2025 at 03:36:39PM +0100, Frederic Weisbecker wrote:
> > > A full memory barrier in the RCU-PREEMPT task unblock path advertizes
> > > to order the context switch (or rather the accesses prior to
> > > rcu_read_unlock()) with the expedited grace period fastpath.
> > >
> > > However the grace period can not complete without the rnp calling into
> > > rcu_report_exp_rnp() with the node locked. This reports the quiescent
> > > state in a fully ordered fashion against updater's accesses thanks to:
> > >
> > > 1) The READ-SIDE smp_mb__after_unlock_lock() barrier accross nodes
> > > locking while propagating QS up to the root.
> > >
> > > 2) The UPDATE-SIDE smp_mb__after_unlock_lock() barrier while holding the
> > > the root rnp to wait/check for the GP completion.
> > >
> > > 3) The (perhaps redundant given step 1) and 2)) smp_mb() in rcu_seq_end()
> > > before the grace period completes.
> > >
> > > This makes the explicit barrier in this place superflous. Therefore
> > > remove it as it is confusing.
> > >
> > > Signed-off-by: Frederic Weisbecker <frede...@kernel.org>
> >
> > Still cannot see a problem with this, but still a bit nervous.
>
> Where is the challenge in life if we manage to fall alseep within a minute
> at bedtime?
;-) ;-) ;-)
Suppose that there was an issue with this that we are somehow not spotting.
How would you go about debugging it?
Thanx, Paul
> > Acked-by: Paul E. McKenney <paul...@kernel.org>
>
> Thanks!
