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? > > Acked-by: Paul E. McKenney <paul...@kernel.org> Thanks!
