[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.