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 :

quoted

quoted

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."

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