[Libguestfs] [nbdkit PATCH 3/7] RFC: protocol: Only send EOVERFLOW when valid

[Eric Blake]

On 5/11/19 5:51 PM, Wouter Verhelst wrote:

> 
> OTOH, for backcompat reasons it is reasonable to state that older
> versions of nbd-server could send pretty much anything over the wire[1],
> and that clients should therefore treat any nonzero value as an unknown
> error.
> 
> I think that might also be a correct way to deal with error numbers in
> cases where the client does not know what to do with it.
> 
> [1] I originally thought that errno values were way more standardized
> than they happen to be in practice, and so the initial error handling in
> nbd-server just sent the value of errno, whatever it happened to be,
> over the wire. That worked just fine if client and server were the same
> platform -- and more so since all the client would ever do when it saw
> an error was yell "the server sent error code X" and abort, so that the
> actual error number didn't even matter -- but it obviously wasn't ideal;
> and when we chose the error values that got written in stone, we chose
> the errno values that Linux/x86 uses for the types of errors that seemed
> reasonable. What older servers sent is however not really defined, and
> therefore should be treated as nasal daemons.
> 
> [...]
>> SHOULD NOT rather than MUST NOT, as a server may still choose to expose
>> non-standard errors over the wire if a client might benefit from those
>> errors, and a well-written client will squash non-standard errors
>> received over the wire back to EINVAL.
> 
> Indeed; I think that is what we should do.
> 
>> So the question at hand is whether I should patch the NBD spec to
>> recommend that a server SHOULD NOT send EOVERFLOW except in response to
>> NBD_CMD_READ when the NBD_CMD_FLAG_DF bit is set (similar to my proposed
>> wording that a server SHOULD NOT send ENOTSUP except in response to
>> NBD_CMD_FLAG_FAST_ZERO).
> 
> I think we can say that, but we should definitely also say that a client
> should treat unknown errors in a particular way. Possibly "abort the
> connection and give up", but something.
> 

I think enough existing clients just silently treat unknown server
errors as EINVAL to make that worth specifying (as a SHOULD, rather than
MUST), rather than aborting the connection. So I wend ahead and added
this sentence on top of my other changes:

+The client SHOULD treat an unexpected error value as if it had been
+`NBD_EINVAL`, rather than disconnecting from the server.
+


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190514/c9fba42d/attachment.sig>