Re: [PATCH v1 06/11] rcu: Enable RCU callbacks to benefit from expedited grace periods

[Frederic Weisbecker <frederic@kernel.org>]

Le Mon, Jul 20, 2026 at 09:55:42AM -0700, Paul E. McKenney a écrit :
> On Mon, Jul 20, 2026 at 04:22:33PM +0200, Frederic Weisbecker wrote:
> > Le Tue, Jul 14, 2026 at 11:48:08AM -0700, Paul E. McKenney a écrit :
> > > > I have similar concerns about the three smp_mb() in
> > > > get_state_synchronize_rcu_full(). It could be just two (rcu_seq_snap()
> > > > has a barrier that could be just one). Not sure if that matters but,
> > > > just wanted to point that.
> > > 
> > > We need the one at the beginning of get_state_synchronize_rcu_full(),
> > > but from what I can see, not the ones in the calls to rcu_seq_snap().
> > > I blame laziness.  We could make an rcu_seq_snap_no_ordering() that
> > > didn't have the smp_mb(), but I didn't believe that the overhead would
> > > be visible at the system level.
> > 
> > It isn't so much about performance than being clear about ordering
> > expectations. Though we could argue that grace period polling can be
> > about performance.
> > 
> > But in general rcu_seq_snap() advertizes:
> > 
> >    READ seq
> >    smp_mb() /* Above access must not bleed into critical section. */
> > 
> > This doesn't tell much. Which critical section? That's not used on
> > read side.
> 
> Fair question!
> 
> And the answer is "any critical section that might later be executed by
> the current task."

But why does it matter, what could go wrong for example?

> 
> Would it help if I made that comment read as follows, separately from
> Puranjay's series?
> 
> 	// The above access must not bleed into any later RCU read-side
> 	// critical section executed by the current task.
> 
> 							Thanx, Paul

-- 
Frederic Weisbecker
SUSE Labs