Hi, At 15:24 +0200 on 14 Aug (1502724279), Dario Faggioli wrote: > On Mon, 2017-08-14 at 11:39 +0100, Tim Deegan wrote: > > At 11:19 +0200 on 14 Aug (1502709563), Dario Faggioli wrote: > > > 3) CPU2 is not in idle_cpumask, and so it will not be in the > > > sampled > > > mask, but the first check of rcu_pending() will lead acknowledge > > > quiescence, and calling of cpu_quiet(); > > > > Yep. And because it's not yet in idle_cpumask, it _will_ check > > rcu_pending() before idling. I think that needs an smp_mb() between > > setting the idle_cpumask and checking rcp->cur, and likewise between > > rcp->cur++ and cpumask_andnot() in rcu_start_batch(). > > > So, the latter, I'm putting it there already, by importing Linux's > c3f59023, "Fix RCU race in access of nohz_cpu_mask" (in this ver > patch).
Yep, looks correct to me. > About the former... I'm not sure which check of rcp->cur you're > referring to. I think it's the one in rcu_check_quiescent_state(), but > then, I'm not sure where to actually put the barrier... I mean whatever one causes the CPU to DTRT about the new grace period. AFAICT that's the one in __rcu_pending(). The important thing is that that read mustn't be allowed to happen before the write to the idle_cpumask. I'd be inclined to put the barrier right after the cpumask_set_cpu() in rcu_idle_enter(). > I'll keep looking, but any advice is welcome. Even after all these > years, barriers still gives me headache. :-P Me too! :) Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
