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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Mon, 2017-08-14 at 11:39 +0100, Tim Deegan wrote:
> Hi,
> 
Hey,

> At 11:19 +0200 on 14 Aug (1502709563), Dario Faggioli wrote:
> > Therefore, it looks to me that the race can be avoided by making
> > sure
> > that there is at least one check of rcu_pending(), after a CPU has
> > called rcu_enter_idle(). This basically means moving
> > rcu_idle_enter()
> > up.
> 
> Sounds plausible.
> 
Great to hear you think that! :-D

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

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'll keep looking, but any advice is welcome. Even after all these
years, barriers still gives me headache. :-P

Thanks for looking at the patches,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel