>>> On 30.04.15 at 15:28, wrote:
>>> On 30.04.15 at 15:28, wrote:
> This patch refactors grant table locking. It splits the previous
> single spinlock per grant table into multiple locks. The heavily
> modified components of the grant table (the maptrack state and the
> active entries) are now pr
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
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 d
At 14:28 +0100 on 30 Apr (1430404124), David Vrabel wrote:
> +/*
> + * N.B.: while taking the left side maptrack spinlock prevents
> + * any mapping changes, the right side active entries could be
> + * changing while we are counting.
IIRC, the lX/rX variables are local/remote rat