From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH] xen: sched: don't call hooks of the wrong scheduler via VCPU2OP Date: Fri, 17 Mar 2017 13:22:35 +0100 Message-ID: <1489753355.15340.3.camel@citrix.com> References: <148969985491.18518.5789656764002800021.stgit@Palanthas.fritz.box> <58CBA17E02000078001441F0@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7009505997487987473==" 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 1coqu5-0002k5-Qj for xen-devel@lists.xenproject.org; Fri, 17 Mar 2017 12:22:45 +0000 In-Reply-To: <58CBA17E02000078001441F0@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Jan Beulich Cc: Juergen Gross , xen-devel@lists.xenproject.org, George Dunlap List-Id: xen-devel@lists.xenproject.org --===============7009505997487987473== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-S87jBYsSa2wsp7ygSu79" --=-S87jBYsSa2wsp7ygSu79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2017-03-17 at 01:42 -0600, Jan Beulich wrote: > > > > On 16.03.17 at 22:30, wrote: > > +{ > > +=C2=A0=C2=A0=C2=A0=C2=A0struct domain *d =3D v->domain; > > + > > +=C2=A0=C2=A0=C2=A0=C2=A0if ( likely(d->cpupool !=3D NULL) ) > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return d->cpupool->sch= ed; > > + > > +=C2=A0=C2=A0=C2=A0=C2=A0/* v->processor never changes for idle vcpus, = so using it here > > is safe */ > > +=C2=A0=C2=A0=C2=A0=C2=A0if ( likely(is_idle_domain(d)) ) > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return per_cpu(schedul= er, v->processor); > > +=C2=A0=C2=A0=C2=A0=C2=A0else > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return &ops; >=20 > Having read through the description, I don't think I can conclude > why using &ops here is correct (or at least benign). And even if > this was explained in the description, I think a brief comment > would be rather desirable here (the more that it having been > &ops implicitly was wrong before as per the description). >=20 Well, looking at all the callers, basically we never return ops. I guess I was being overly conservative about keeping somewhat intact the implant of original code. I'll send v2 with both a comment and an ASSERT() for making things more clear. Thanks, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-S87jBYsSa2wsp7ygSu79 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 iQIcBAABCAAGBQJYy9UMAAoJEBZCeImluHPuAFcP/3TvqSS/M9JpHt9oeONScxKO EMk/Ra7F5xwcPrhszqnaiCe79xu845Z7eRrOZcOlxgHFvd6vqEgumq441p35y51Y i4LvjS1aVr2tdPMJ2AtJly84m0p2vLtqPOAQWnXiibnUPHfXFtXGVRHg5Y53f6be RL/fgCLCi666UBU02kJJjqayurCrzqdTEPuvcSkEZXYCKeKG2ksrXYXQYlPIPPdK YYH7Xnl/wQCWO5EXY/hgsqBp89+EAJLGVaw/xE6Q9HKOs4RkQSmEgCVp4EqEJYcy Qizwj7KS93EFKQy4pZFV46gBkXLAqmrVnrsi40jkqpz7GZwS4E9PpwqRxR5upQF6 b29tzXtWrLeC33ZzNa2HSTWF0ZYAOgAAQvCm4MIVwYKnIf6ttXY07pPKSOgQPzOX tcyTINHjfoOs9g7tXA5h+ZJr8dXjCKs0Y1DOdJoZI7S3wTeefOG8/y4Y5rG5RUWq 5xB8dSdS/frFwrTH4NvmHM/ooNPI+GDkeWKubzsV8yXofBzwzikEnN0Zx9DhPoOO fLJ/6aLW9PBaFRzSuoMHtwCmrihj/K38nuCRhGDilcgOET8fTKiIAGcTm+Ho3rqu 1SwmpyZJ0VRKTzEt5zfI5/lVWAEeX+9/+z71ynqpOVV2R0AIbHqiKb2JEFbL5mZo ZeLef8PJnkNW4Y03S20C =X21h -----END PGP SIGNATURE----- --=-S87jBYsSa2wsp7ygSu79-- --===============7009505997487987473== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============7009505997487987473==--