On 3/25/19 11:05 AM, Eric Blake wrote: > More to the point, the behavior of qemu for a (structured) error reply > to NBD_CMD_BLOCK_STATUS with no extent->length was to keep the > connection alive (both before and after commit 7f86068d) - the > difference in behavior for this hunk of the patch is only visible for > simple error replies. (Here's the hacks I applied to the server, to test > forced error replies to NBD_CMD_BLOCK_STATUS, whether structured or simple: > > > From 22b4181f887d3b782695dbb11fcc1759281fc51e Mon Sep 17 00:00:00 2001 > From: Eric Blake <ebl...@redhat.com> > Date: Sat, 23 Mar 2019 07:19:33 -0500 > Subject: [PATCH 1/2] nbd: Debug patch to force NBD_CMD_BLOCK_STATUS failure > > Hack to test whether the client is robust to block status failure. > > Signed-off-by: Eric Blake <ebl...@redhat.com> > --- > nbd/server.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/nbd/server.c b/nbd/server.c > index fd013a2817a..94d0c9f4e9e 100644 > --- a/nbd/server.c > +++ b/nbd/server.c > @@ -2269,6 +2269,8 @@ static coroutine_fn int > nbd_handle_request(NBDClient *client, > "discard failed", errp); > > case NBD_CMD_BLOCK_STATUS: > + return nbd_send_generic_reply(client, request->handle, -EINVAL,
As long as I'm hacking things, forcing -ENOMEM here is more instructive (as both -EINVAL and -EIO can be set in client-side code in nbd-client.c regardless of what the server sent, but -ENOMEM is a fairly reliable witness of the actual error message being reported by the server). That is, when trying to decipher what clients do to a particular forced server error, seeing the server's 'Cannot allocate memory' is a good sign that the error message properly transferred across all the needed layers, rather than getting replaced somewhere along the way. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
