Le Tue, Mar 18, 2025 at 10:17:16AM -0700, Paul E. McKenney a écrit : > On Fri, Mar 14, 2025 at 03:36:38PM +0100, Frederic Weisbecker wrote: > > When a grace period is started, the ->expmask of each node is set up > > from sync_exp_reset_tree(). Then later on each leaf node also initialize > > its ->exp_tasks pointer. > > > > This means that the initialization of the quiescent state of a node and > > the initialization of its blocking tasks happen with an unlocked node > > gap in-between. > > > > It happens to be fine because nothing is expected to report an exp > > quiescent state within this gap, since no IPI have been issued yet and > > every rdp's ->cpu_no_qs.b.exp should be false. > > > > However if it were to happen by accident, the quiescent state could be > > reported and propagated while ignoring tasks that blocked _before_ the > > start of the grace period. > > > > Prevent such trouble to happen in the future and initialize both the > > quiescent states mask to report and the blocked tasks head from the same > > node locked block. > > > > If a task blocks within an RCU read side critical section before > > sync_exp_reset_tree() is called and is then unblocked between > > sync_exp_reset_tree() and __sync_rcu_exp_select_node_cpus(), the QS > > won't be reported because no RCU exp IPI had been issued to request it > > through the setting of srdp->cpu_no_qs.b.exp. > > > > Signed-off-by: Frederic Weisbecker <frede...@kernel.org> > > OK, and because ->expmaskinit has all bits set for all CPUs that have > ever been online, the ends of any corresponding readers will give up at > the beginning of the first pass of the loop in __rcu_report_exp_rnp(). > This is because the ->expmask is guaranteed to be non-zero. (Which is > kind of what you are saying in the last paragraph of your commit log, > just digging down another layer.)
Exactly! Thanks.
