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
