Re: [Qemu-devel] [PATCH 11/19] io/channel-socket: qio_channel_socket_writev handle EPIPE

[Daniel P. Berrange]

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 :|