Re: [Xen-devel] [PATCH 3/5] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.

[Tim Deegan <tim@xxxxxxx>]

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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel