Re: [Xen-devel] [PATCH 12/14] xen-blkback: safely unmap grants in case they are still in use

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 23/01/15 15:47, Roger Pau Monné wrote:
> El 23/01/15 a les 15.54, David Vrabel ha escrit:
>> On 23/01/15 14:31, Roger Pau Monné wrote:
>>> El 19/01/15 a les 16.51, David Vrabel ha escrit:
>>>> +          if (invcount) {
>>>> +                  ret = gnttab_unmap_refs(unmap, NULL, unmap_pages, 
>>>> invcount);
>>>>                    BUG_ON(ret);
>>>> -                  put_free_pages(blkif, unmap_pages, invcount);
>>>> -                  invcount = 0;
>>>> +                  xen_blkbk_unmap_done(blkif, unmap_pages, invcount);
>>>>            }
>>>> -  }
>>>> -  if (invcount) {
>>>> -          ret = gnttab_unmap_refs(unmap, NULL, unmap_pages, invcount);
>>>> -          BUG_ON(ret);
>>>> -          put_free_pages(blkif, unmap_pages, invcount);
>>>> +          pages += batch;
>>>> +          num -= batch;
> 
> This should be fixed to at least be (which is still not fully correct,
> but it's better):
> 
> pages += invcount;
> num -= invcount;
> 
> I hope an example will clarify this, suppose we have the following pages
> array:
> 
> pages[0] = persistent grant
> pages[1] = persistent grant
> pages[2] = regular grant
> pages[3] = persistent grant
> pages[4] = regular grant
> 
> And batch is 1. In this case, the unmapped grant will be pages[2], but
> then due to the code below pages will be updated to point to &pages[1],
> which has already been scanned. If this was done correctly pages should
> point to &pages[3]. As said, it's not really a bug, but the loop is
> sub-optimal.

Ah ha.  Thanks for the clear explanation.

gnttab_blkback_unmap_prepare() stops once its been through the whole
batch regardless of whether it filled the array with ops so we don't
check a page twice but this does mean we have a sub-optimal number of ops.

David

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