When sending a NBD_CMD_DISC message there is no reply expected,
however, the nbd_read_eof() coroutine is still waiting for a reply.
In a plain NBD connection this doesn't matter as it will just get an
EOF, however, on a TLS connection it will get an interrupted TLS data
packet. The nbd_read_eof() will then print an error message on the
console due to missing reply to NBD_CMD_DISC.
This can be seen with qemu-img
$ qemu-img info \
--object tls-creds-x509,dir=tlsdir,id=tls0,endpoint=client \
--image-opts driver=nbd,host=127.0.0.1,port=9000,tls-creds=tls0
qemu-img: Cannot read from TLS channel: Input/output error
image: nbd://127.0.0.1:9000
file format: nbd
virtual size: 10M (10485760 bytes)
disk size: unavailable
Simply setting the 'quit' flag after sending NBD_CMD_DISC is enough to
get the coroutine to stop waiting for a reply and thus supress the error
message. This fixes a regression introduced in
commit be41c100c0d67f6072ddd4910c4b6f7d239f025f
Author: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com>
Date: Fri May 26 14:09:13 2017 +0300
nbd/client.c: use errp instead of LOG
Move to modern errp scheme from just LOGging errors.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com>
Message-Id: <20170526110913.89098-1-vsement...@virtuozzo.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
---
block/nbd-client.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/nbd-client.c b/block/nbd-client.c
index 76e9ca3abe..5f63e4b8f1 100644
--- a/block/nbd-client.c
+++ b/block/nbd-client.c
@@ -961,6 +961,7 @@ void nbd_client_close(BlockDriverState *bs)
}
nbd_send_request(client->ioc, &request);
+ client->quit = true;
nbd_teardown_connection(bs);
}
--
2.19.1
