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 <vsement...@virtuozzo.com> > > > --- > > > 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 :|