RE: [PATCH v2 for-5.0] xen-block: Fix double qlist remove and request leak

[Paul Durrant]

> -----Original Message-----
> From: Anthony PERARD <address@hidden>
> Sent: 06 April 2020 15:02
> To: address@hidden
> Cc: address@hidden; Anthony PERARD <address@hidden>; Stefano Stabellini
> <address@hidden>; Paul Durrant <address@hidden>; Stefan Hajnoczi 
> <address@hidden>; Kevin
> Wolf <address@hidden>; Max Reitz <address@hidden>; address@hidden; qemu-
> address@hidden
> Subject: [PATCH v2 for-5.0] xen-block: Fix double qlist remove and request 
> leak
> 
> Commit a31ca6801c02 ("qemu/queue.h: clear linked list pointers on
> remove") revealed that a request was removed twice from a list, once
> in xen_block_finish_request() and a second time in
> xen_block_release_request() when both function are called from
> xen_block_complete_aio(). But also, the `requests_inflight' counter is
> decreased twice, and thus became negative.
> 
> This is a bug that was introduced in bfd0d6366043

NIT: I guess you should quote the patch title here as well.

> , where a `finished'
> list was removed.
> 
> That commit also introduced a leak of request in xen_block_do_aio().
> That function calls xen_block_finish_request() but the request is
> never released after that.
> 
> To fix both issue, we do two changes:
> - we squash finish_request() and release_request() together as we want
>   to remove a request from 'inflight' list to add it to 'freelist'.
> - before releasing a request, we need to let now the result to the
>   other end,

"we need to let the other end know the result"

> thus we should call xen_block_send_response() before
>   releasing a request.
> 
> The first change fix the double QLIST_REMOVE() as we remove the extra

s/fix/fixes

> call. The second change makes the leak go away because if we want to
> call finish_request(), we need to call a function that do all of

s/do/does

> finish, send response, and release.
> 
> Fixes: bfd0d6366043 ("xen-block: improve response latency")
> Signed-off-by: Anthony PERARD <address@hidden>

The code looks ok, so with the cosmetic fixes...

Reviewed-by: Paul Durrant <address@hidden>