qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 1/3] nbd-client: avoid read_reply_co entry if


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v2 1/3] nbd-client: avoid read_reply_co entry if send failed
Date: Tue, 29 Aug 2017 14:13:16 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

On 08/29/2017 07:27 AM, Stefan Hajnoczi wrote:
> The following segfault is encountered if the NBD server closes the UNIX
> domain socket immediately after negotiation:
> 

> 
> In the mean time blk_co_preadv() can be called and nbd_coroutine_end()
> calls aio_wake() on read_reply_co.  At this point in time
> read_reply_co's ctx isn't set because it has never been entered yet.
> 
> This patch simplifies the nbd_co_send_request() ->
> nbd_co_receive_reply() -> nbd_coroutine_end() lifecycle to just
> nbd_co_send_request() -> nbd_co_receive_reply().  The request is "ended"
> if an error occurs at any point.  Callers no longer have to invoke
> nbd_coroutine_end().

Vladimir's work also eliminated a separate call to nbd_coroutine_end.
There will be some interesting rebase issues to resolve between the two,
but I think we'll get there.

> 
> This cleanup also eliminates the segfault because we don't call
> aio_co_schedule() to wake up s->read_reply_co if sending the request
> failed.  It is only necessary to wake up s->read_reply_co if a reply was
> received.
> 
> Note this only happens with UNIX domain sockets on Linux.  It doesn't
> seem possible to reproduce this with TCP sockets.
> 
> Suggested-by: Paolo Bonzini <address@hidden>
> Signed-off-by: Stefan Hajnoczi <address@hidden>
> ---
>  block/nbd-client.c | 25 +++++++++----------------
>  1 file changed, 9 insertions(+), 16 deletions(-)
> 

Reviewed-by: Eric Blake <address@hidden>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]