[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 12/14] xen-blkback: safely unmap grants in case they are still in use
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: >>> From: Jenny Herbert <jennifer.herbert@xxxxxxxxxx> >>> >>> +static void xen_blkbk_unmap(struct xen_blkif *blkif, >>> + struct grant_page *pages[], >>> + int num) >>> +{ >>> + struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST]; >>> + struct page *unmap_pages[BLKIF_MAX_SEGMENTS_PER_REQUEST]; >>> + unsigned int invcount = 0; >>> + int ret; >>> + >>> + while (num) { >>> + unsigned int batch = min(num, BLKIF_MAX_SEGMENTS_PER_REQUEST); >>> + >>> + invcount = xen_blkbk_unmap_prepare(blkif, pages, batch, >>> + unmap, unmap_pages); >> >> I would add: >> >> BUG_ON(invcount != batch); > > I'm confused. Surely invcount < batch is valid if one or more pages > within this batch are persistently mapped? Yes, my bad, see below. > >>> + 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. Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |