At Tue, 30 Jul 2013 15:48:02 +0200, Stefan Hajnoczi wrote: > > On Fri, Jul 26, 2013 at 03:10:45PM +0900, MORITA Kazutaka wrote: > > If qemu_co_recv/send doesn't return the specified length, it means > > that an error happened. > > > > Tested-and-reviewed-by: Liu Yuan <namei.u...@gmail.com> > > Signed-off-by: MORITA Kazutaka <morita.kazut...@lab.ntt.co.jp> > > --- > > block/sheepdog.c | 16 ++++++++-------- > > 1 file changed, 8 insertions(+), 8 deletions(-) > > > > diff --git a/block/sheepdog.c b/block/sheepdog.c > > index 6a41ad9..c6e9b89 100644 > > --- a/block/sheepdog.c > > +++ b/block/sheepdog.c > > @@ -489,13 +489,13 @@ static coroutine_fn int send_co_req(int sockfd, > > SheepdogReq *hdr, void *data, > > int ret; > > > > ret = qemu_co_send(sockfd, hdr, sizeof(*hdr)); > > - if (ret < sizeof(*hdr)) { > > + if (ret != sizeof(*hdr)) { > > error_report("failed to send a req, %s", strerror(errno)); > > Does this rely on qemu_co_send_recv() getting ret=-1 errno=EPIPE from > iov_send_recv()? I want to check that I understand what happens when > the socket is closed by the other side.
Yes, when the socket is closed by the peer, qemu_co_send_recv() returns a short write (if some bytes are already sent) or -1 (if no data is sent). The current sheepdog driver doesn't work correctly for the latter case because it compares -1 and an unsigned value. This doesn't happen for the current qemu-io and qemu-img because they terminate with SIGPIPE when the connection is closed by the peer. Thanks, Kazutaka