Re: [Xen-devel] [PATCHv8 2/3] gnttab: per-active entry locking

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.05.15 at 16:15, <david.vrabel@xxxxxxxxxx> wrote:
> +static inline struct active_grant_entry *
> +active_entry_acquire(struct grant_table *t, grant_ref_t e)
> +{
> +    struct active_grant_entry *act;
> +
> +    /* 
> +     * not perfect, but better than nothing for a debug build
> +     * sanity check
> +     */

Comment style.

> @@ -546,15 +554,28 @@ static void mapcount(
>  
>      *wrc = *rdc = 0;
>  
> +    /* 
> +     * N.B.: while taking the local maptrack spinlock prevents any
> +     * mapping changes, the remote active entries could be changing
> +     * while we are counting. The caller has to hold the grant table
> +     * write lock, or some other mechanism should be used to prevent
> +     * concurrent changes during this operation.  This is tricky
> +     * because we can't promote a read lock into a write lock.
> +     */
> +    ASSERT(rw_is_locked(&rd->grant_table->lock));

So both callers only hold the read lock - what is this "other mechanism"
that they employ?

> @@ -2602,9 +2629,17 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t 
> ref_b)
>  {
>      struct domain *d = rcu_lock_current_domain();
>      struct grant_table *gt = d->grant_table;
> -    struct active_grant_entry *act;
> +    struct active_grant_entry *act_a = NULL;
> +    struct active_grant_entry *act_b = NULL;
>      s16 rc = GNTST_okay;
>  
> +    if ( ref_a == ref_b )
> +        /*
> +         * noop, so avoid acquiring the same active entry
> +         * twice which would case a deadlock.

cause

Jan


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