[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 11/19] io/channel-socket: qio_channel_socket_wri
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] [PATCH 11/19] io/channel-socket: qio_channel_socket_writev handle EPIPE |
Date: |
Tue, 30 May 2017 16:29:11 +0100 |
User-agent: |
Mutt/1.8.0 (2017-02-23) |
On Tue, May 30, 2017 at 06:15:07PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> 30.05.2017 18:04, Daniel P. Berrange wrote:
> > On Tue, May 30, 2017 at 05:30:44PM +0300, Vladimir Sementsov-Ogievskiy
> > wrote:
> > > Return QIO_CHANNEL_ERR_EPIPE on EPIPE, we will need it to improve error
> > > path in nbd server.
> > >
> > > Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
> > > ---
> > > include/io/channel.h | 1 +
> > > io/channel-socket.c | 2 +-
> > > 2 files changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/io/channel.h b/include/io/channel.h
> > > index 5d48906998..5529c2da31 100644
> > > --- a/include/io/channel.h
> > > +++ b/include/io/channel.h
> > > @@ -38,6 +38,7 @@ typedef struct QIOChannel QIOChannel;
> > > typedef struct QIOChannelClass QIOChannelClass;
> > > #define QIO_CHANNEL_ERR_BLOCK -2
> > > +#define QIO_CHANNEL_ERR_EPIPE -3
> > > typedef enum QIOChannelFeature QIOChannelFeature;
> > > diff --git a/io/channel-socket.c b/io/channel-socket.c
> > > index 53386b7ba3..50f9f966c6 100644
> > > --- a/io/channel-socket.c
> > > +++ b/io/channel-socket.c
> > > @@ -542,7 +542,7 @@ static ssize_t qio_channel_socket_writev(QIOChannel
> > > *ioc,
> > > }
> > > error_setg_errno(errp, errno,
> > > "Unable to write to socket");
> > > - return -1;
> > > + return errno == EPIPE ? QIO_CHANNEL_ERR_EPIPE : -1;
> > > }
> > > return ret;
> > Ewwww, no. We don't want to go down the road of special casing
> > further errno values for every error scenario.
>
> I need to distinguish client socket closed without reading nbd server reply
> from other errors, because this is a valid behavior accordingly to the
> protocol.
> Any way to do this? Hmm, I can examine the contents of errp, of course, but
> I'm afraid it would be even less appropriate. This is funny: user has this
> information in errp message, but the code - doesn't..
>
> Alternatively:
> 1. not report errors on sending reply after OPT_ABORT at all
> 2. report all errors, (including this EPIPE, which actually is not a
> failure)
>
> Paolo, what do you think?
>
> (current behavior is (1))
I'm not seeing any problem with continuing with (1). Once we've received
an OPT_ABORT msg from the client, we know it is going away, so no further
errors we get matter from that point onwards.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
- [Qemu-devel] [PATCH 00/19] nbd errors and traces refactoring, Vladimir Sementsov-Ogievskiy, 2017/05/30
- [Qemu-devel] [PATCH 08/19] nbd/server: get rid of fail: return rc, Vladimir Sementsov-Ogievskiy, 2017/05/30
- [Qemu-devel] [PATCH 07/19] nbd/server: nbd_negotiate: fix error path, Vladimir Sementsov-Ogievskiy, 2017/05/30
- [Qemu-devel] [PATCH 10/19] nbd/server: refactor nbd_trip, Vladimir Sementsov-Ogievskiy, 2017/05/30
- [Qemu-devel] [PATCH 13/19] nbd/server: return original error codes, Vladimir Sementsov-Ogievskiy, 2017/05/30
- [Qemu-devel] [PATCH 09/19] nbd/server: rename rc to ret, Vladimir Sementsov-Ogievskiy, 2017/05/30
- [Qemu-devel] [PATCH 05/19] nbd/server: refactor nbd_co_receive_request, Vladimir Sementsov-Ogievskiy, 2017/05/30