On Sun, Jun 11, 2017 at 02:37:14PM +0200, Max Reitz wrote: > qemu proper has done so for 13 years > (8a7ddc38a60648257dc0645ab4a05b33d6040063), qemu-img and qemu-io have > done so for four years (526eda14a68d5b3596be715505289b541288ef2a). > Ignoring this signal is especially important in qemu-nbd because > otherwise a client can easily take down the qemu-nbd server by dropping > the connection when the server wants to send something, for example: > > $ qemu-nbd -x foo -f raw -t null-co:// & > [1] 12726 > $ qemu-io -c quit nbd://localhost/bar > can't open device nbd://localhost/bar: No export with name 'bar' available > [1] + 12726 broken pipe qemu-nbd -x foo -f raw -t null-co:// > > In this case, the client sends an NBD_OPT_ABORT and closes the > connection (because it is not required to wait for a reply), but the > server replies with an NBD_REP_ACK (because it is required to reply). > > Signed-off-by: Max Reitz <mre...@redhat.com> > --- > I tried to find some other reproducer instead of using a qemu client > (e.g. nping -c 1 --tcp-connect localhost -p 10809, which gives the same > pattern of <FIN-ACK, >PSH-ACK, <RST as qemu-io) but to no avail. This > only results in the write being successful and the next read failing; > interestingly, sendmsg()'s man page states that EPIPE is only returned > when the local end is closed. However, I have not found the NBD server > to close that local end anywhere. > > In any case, ignoring SIGPIPE is the right thing to do. We get an EPIPE > anyway, and this is fully sufficient to let us know that the connection > is dead. > --- > qemu-nbd.c | 4 ++++ > 1 file changed, 4 insertions(+)
Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com>
signature.asc
Description: PGP signature
