diff mbox

[RESEND,1/8] gnttab: drop useless locking

Message ID 59932378020000780016FEC6@prv-mh.provo.novell.com (mailing list archive)
State New, archived
Headers show

Commit Message

Jan Beulich Aug. 15, 2017, 2:38 p.m. UTC 
Holding any lock while accessing the maptrack entry fields is
pointless, as these entries are protected by their associated active
entry lock (which is being acquired later, before re-validating the
fields read without holding the lock).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

Comments

Andrew Cooper Aug. 15, 2017, 4:08 p.m. UTC | #1 
On 15/08/17 15:38, Jan Beulich wrote:
> Holding any lock while accessing the maptrack entry fields is
> pointless, as these entries are protected by their associated active
> entry lock (which is being acquired later, before re-validating the
> fields read without holding the lock).
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
diff mbox

Patch

--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1140,19 +1140,14 @@  __gnttab_unmap_common(
     smp_rmb();
     map = &maptrack_entry(lgt, op->handle);
 
-    grant_read_lock(lgt);
-
     if ( unlikely(!read_atomic(&map->flags)) )
     {
-        grant_read_unlock(lgt);
         gdprintk(XENLOG_INFO, "Zero flags for handle %#x\n", op->handle);
         op->status = GNTST_bad_handle;
         return;
     }
 
     dom = map->domid;
-    grant_read_unlock(lgt);
-
     if ( unlikely((rd = rcu_lock_domain_by_id(dom)) == NULL) )
     {
         /* This can happen when a grant is implicitly unmapped. */