| Message ID | 594A5A9C02000078001650BE@prv-mh.provo.novell.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 21/06/17 10:38, Jan Beulich wrote: > 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 <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- 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 = lgt->maptrack_limit; unsigned int kind = 0; /* @@ -726,10 +726,10 @@ static unsigned int mapkind( */ ASSERT(percpu_rw_is_write_locked(&rd->grant_table->lock)); - for ( handle = 0; !(kind & MAPKIND_WRITE) && - handle < lgt->maptrack_limit; handle++ ) + smp_rmb(); + + for ( handle = 0; !(kind & MAPKIND_WRITE) && handle < limit; handle++ ) { - smp_rmb(); map = &maptrack_entry(lgt, handle); if ( !(map->flags & (GNTMAP_device_map|GNTMAP_host_map)) || map->domid != rd->domain_id )
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 <jbeulich@suse.com> gnttab: limit mapkind()'s iteration count 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 <jbeulich@suse.com> --- 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 = lgt->maptrack_limit; unsigned int kind = 0; /* @@ -726,10 +726,10 @@ static unsigned int mapkind( */ ASSERT(percpu_rw_is_write_locked(&rd->grant_table->lock)); - for ( handle = 0; !(kind & MAPKIND_WRITE) && - handle < lgt->maptrack_limit; handle++ ) + smp_rmb(); + + for ( handle = 0; !(kind & MAPKIND_WRITE) && handle < limit; handle++ ) { - smp_rmb(); map = &maptrack_entry(lgt, handle); if ( !(map->flags & (GNTMAP_device_map|GNTMAP_host_map)) || map->domid != rd->domain_id )