From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: [PATCH 10/11] gnttab: limit mapkind()'s iteration count Date: Wed, 21 Jun 2017 03:38:04 -0600 Message-ID: <594A5A9C02000078001650BE@prv-mh.provo.novell.com> References: <594A57B10200007800165012@prv-mh.provo.novell.com> <594A57B10200007800165012@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part2911376C.3__=" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dNc5R-0000hF-0X for xen-devel@lists.xenproject.org; Wed, 21 Jun 2017 09:38:09 +0000 In-Reply-To: <594A57B10200007800165012@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: xen-devel Cc: Stefano Stabellini , Wei Liu , George Dunlap , Andrew Cooper , Ian Jackson , Tim Deegan List-Id: xen-devel@lists.xenproject.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part2911376C.3__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline There's no need for the function to observe increases of the maptrack table (which can occur as the maptrack lock isn't being held) - actual population of maptrack entries is excluded while we're here (by way of holding the respective grant table lock for writing, while code populating entries acquires it for reading). Latch the limit ahead of the loop, allowing for the barrier to move out, too. Signed-by: Jan Beulich --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c @@ -712,7 +712,7 @@ static unsigned int mapkind( struct grant_table *lgt, const struct domain *rd, unsigned long mfn) { struct grant_mapping *map; - grant_handle_t handle; + grant_handle_t handle, limit =3D lgt->maptrack_limit; unsigned int kind =3D 0; =20 /* @@ -726,10 +726,10 @@ static unsigned int mapkind( */ ASSERT(percpu_rw_is_write_locked(&rd->grant_table->lock)); =20 - for ( handle =3D 0; !(kind & MAPKIND_WRITE) && - handle < lgt->maptrack_limit; handle++ ) + smp_rmb(); + + for ( handle =3D 0; !(kind & MAPKIND_WRITE) && handle < limit; = handle++ ) { - smp_rmb(); map =3D &maptrack_entry(lgt, handle); if ( !(map->flags & (GNTMAP_device_map|GNTMAP_host_map)) || map->domid !=3D rd->domain_id ) --=__Part2911376C.3__= Content-Type: text/plain; name="gnttab-mapkind-limit.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="gnttab-mapkind-limit.patch" gnttab: limit mapkind()'s iteration count=0A=0AThere's no need for the = function to observe increases of the maptrack=0Atable (which can occur as = the maptrack lock isn't being held) - actual=0Apopulation of maptrack = entries is excluded while we're here (by way of=0Aholding the respective = grant table lock for writing, while code=0Apopulating entries acquires it = for reading). Latch the limit ahead of=0Athe loop, allowing for the = barrier to move out, too.=0A=0ASigned-by: Jan Beulich = =0A=0A--- a/xen/common/grant_table.c=0A+++ b/xen/common/grant_table.c=0A@@ = -712,7 +712,7 @@ static unsigned int mapkind(=0A struct grant_table = *lgt, const struct domain *rd, unsigned long mfn)=0A {=0A struct = grant_mapping *map;=0A- grant_handle_t handle;=0A+ grant_handle_t = handle, limit =3D lgt->maptrack_limit;=0A unsigned int kind =3D 0;=0A = =0A /*=0A@@ -726,10 +726,10 @@ static unsigned int mapkind(=0A = */=0A ASSERT(percpu_rw_is_write_locked(&rd->grant_table->lock));=0A = =0A- for ( handle =3D 0; !(kind & MAPKIND_WRITE) &&=0A- = handle < lgt->maptrack_limit; handle++ )=0A+ smp_rmb();=0A+=0A+ = for ( handle =3D 0; !(kind & MAPKIND_WRITE) && handle < limit; handle++ = )=0A {=0A- smp_rmb();=0A map =3D &maptrack_entry(lgt, = handle);=0A if ( !(map->flags & (GNTMAP_device_map|GNTMAP_host_map)= ) ||=0A map->domid !=3D rd->domain_id )=0A --=__Part2911376C.3__= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --=__Part2911376C.3__=--