[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
On 14/01/15 15:47, Boris Ostrovsky wrote: > >> +static void xen_blkbk_unmap_and_respond_callback(int result, struct >> gntab_unmap_queue_data *data) >> +{ >> + struct pending_req* pending_req = (struct pending_req*) >> (data->data); >> + struct xen_blkif *blkif = pending_req->blkif; >> + >> + /* BUG_ON used to reproduce existing behaviour, >> + but is this the best way to deal with this? */ >> + BUG_ON(result); >> + /* free page after unmap */ >> + put_free_pages(blkif, data->pages, data->count); >> + >> + /* respond */ >> + make_response(blkif, pending_req->id, >> + pending_req->operation, pending_req->status); >> + free_req(blkif, pending_req); >> + /* >> + * Make sure the request is freed before releasing blkif, >> + * or there could be a race between free_req and the >> + * cleanup done in xen_blkif_free during shutdown. >> + * >> + * NB: The fact that we might try to wake up pending_free_wq >> + * before drain_complete (in case there's a drain going on) >> + * it's not a problem with our current implementation >> + * because we can assure there's no thread waiting on >> + * pending_free_wq if there's a drain going on, but it has >> + * to be taken into account if the current model is changed. >> + */ >> + if (atomic_dec_and_test(&blkif->inflight) && >> atomic_read(&blkif->drain)) { >> + complete(&blkif->drain_complete); >> + } >> + xen_blkif_put(blkif); >> +} >> + >> +static void xen_blkbk_unmap_populate(struct pending_req *req) >> +{ >> + >> + struct gntab_unmap_queue_data* work = &req->gnttab_unmap_data; >> + struct xen_blkif *blkif = req->blkif; >> + struct grant_page **pages = req->segments; >> + unsigned int i, invcount = 0; >> + >> + for (i = 0; i < req->nr_pages; i++) { >> + if (pages[i]->persistent_gnt != NULL) { >> + put_persistent_gnt(blkif, pages[i]->persistent_gnt); >> + continue; >> + } >> + if (pages[i]->handle == BLKBACK_INVALID_HANDLE) >> + continue; >> + >> + req->unmap_pages[invcount] = pages[i]->page; >> + gnttab_set_unmap_op(&req->unmap[invcount], >> vaddr(pages[invcount]->page), >> + GNTMAP_host_map, pages[i]->handle); >> + pages[i]->handle = BLKBACK_INVALID_HANDLE; >> + invcount++; >> + } >> + >> + work->data = req; >> + work->done = &xen_blkbk_unmap_and_respond_callback; >> + work->unmap_ops = req->unmap; >> + work->kunmap_ops = NULL; >> + work->pages = req->unmap_pages; >> + work->count = invcount; >> + >> +} >> + >> +static void xen_blkbk_unmap_and_respond(struct pending_req *req) >> +{ >> + xen_blkbk_unmap_populate(req); >> + gnttab_unmap_refs_async(&req->gnttab_unmap_data); >> +} > > (One more for this patch) > > If you are using async unmap here, I thought new interface requires you > to wait for completion (which should be called from > xen_blkbk_unmap_and_respond_callback()). We complete the request in the done callback so we don't need to wait. David _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |