Re: [Xen-devel] [PATCHv7 2/3] gnttab: refactor locking for scalability

[Tim Deegan <tim@xxxxxxx>]

At 19:03 +0100 on 01 May (1430506982), David Vrabel wrote:
> On 30/04/15 15:34, Tim Deegan wrote:
> > 
> > OK, so here we hold rd->grant_table->lock and act->lock (which is in
> > the rd table) and are going to acquire lgt->maptrack_lock in mapcount().
> > 
> > That means we can't ever have a path holding domA's maptrack lock that
> > acquires domB's gt lock or one of domB's act->locks.  I think that's
> > OK because after this patch the only paths left that hold the maptrack
> > lock can't acquire anything except an act->lock of the same domain.
> > Do I understand that correctly?
> > 
> > Also: because mapcount() itself doesn't take any act->lock, there's no
> > path that holds two act->locks at the same time?
> 
> Um. I think it's easier if we just say you cannot take another lock
> while holding a maptrack_lock since that's currently the case.

Er, yes.  I had misread the locking order, sorry.  So we just need to
say (a) no locks inside the maptrack lock and (b) never take two
act->locks at once.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel