>>> 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
From: Matt Wilson
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 protected by their own spinlocks. The
remaining elements o
