From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 3/5] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started. Date: Mon, 14 Aug 2017 15:24:39 +0200 Message-ID: <1502717079.5719.39.camel@citrix.com> References: <20170814103927.GA68284@deinos.phlegethon.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8333705485090186435==" Return-path: Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhFMS-0002Cm-2G for xen-devel@lists.xenproject.org; Mon, 14 Aug 2017 13:24:52 +0000 In-Reply-To: <20170814103927.GA68284@deinos.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Tim Deegan Cc: xen-devel@lists.xenproject.org, Julien Grall , Stefano Stabellini , Jan Beulich , Andrew Cooper List-Id: xen-devel@lists.xenproject.org --===============8333705485090186435== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-KoYCrxxf1DqjWFi0XSaX" --=-KoYCrxxf1DqjWFi0XSaX Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2017-08-14 at 11:39 +0100, Tim Deegan wrote: > Hi, >=20 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. >=20 > Sounds plausible. >=20 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(); >=20 > Yep.=C2=A0=C2=A0And because it's not yet in idle_cpumask, it _will_ check > rcu_pending() before idling.=C2=A0=C2=A0I think that needs an smp_mb() be= tween > setting the idle_cpumask and checking rcp->cur, and likewise between > rcp->cur++ and cpumask_andnot() in rcu_start_batch(). >=20 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 --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-KoYCrxxf1DqjWFi0XSaX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJZkaSXAAoJEBZCeImluHPuNsIQAOeJeVKG/L4qqMpbTaMyJzP9 zKlEU1gTZZdp1B+dWy+dZwYs64/nOOwmwpoirwy6xg2j9hmCu6f1LIhJEDfLMObB GSUkryv2vPiQ+4CoDEiZXJFEGU2BaXgQMQPd4W3+uU9ttAMKQWQLod99W14eWDNO BC1vZY7Ng+dhuyPQf1VmBtuJffilzEz4hUVI1aUSnfRZmQTVwthGdw4E3MPVV+lr 6K4HfHrDYzxCoNTe7cvYPexokXWog/F9c3vSqB3PWX0eA1sRAuV5BTWOUt5Hjl3s 3SL4NC6Uau9YORq4ZJku4c+260a7EAvHul5RgLMGHeNFlwl7p61dulGC30nL5fMU 7C9HsUiMcALQY1M2m1jBbBKDQc0Lbiot4fd4t/7KntzPStvHK6CnCDrTdbmXjVh+ bkYBaIQ8d6Aw8da5LcExDT3ngwtFWMDq6a5DhvH59qQ7TiPMnM9SXefgzNCzr/a4 VCBm3xnm+Bd8SoEfA05S+BruGe2oqIbjc5pUnTNXzGZR8P1XdAFY4ISNtYcK5/M5 9uw0AI3tMUWiXhLP1bIU7Fkc7ZiJVq51lRteUmkMySdIs6XiVo8veb4Rn+cKBiuH CS7qoTkiSWX/ZEfh9NWBvUPmd5T/PKbgVj49gEJMA4tSFFAIsJsGC0YfSh13LcQP oz9YBpE/c1oKuBm4hsVq =p4xu -----END PGP SIGNATURE----- --=-KoYCrxxf1DqjWFi0XSaX-- --===============8333705485090186435== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============8333705485090186435==--