search for: nbd_einval

...nnections.c index e15a777..c0f0567 100644 --- a/src/connections.c +++ b/src/connections.c @@ -737,6 +737,10 @@ nbd_errno (int error) case EFBIG: case ENOSPC: return NBD_ENOSPC; +#ifdef ESHUTDOWN + case ESHUTDOWN: + return NBD_ESHUTDOWN; +#endif case EINVAL: default: return NBD_EINVAL; diff --git a/src/protocol.h b/src/protocol.h index 4571a3a..74c4527 100644 --- a/src/protocol.h +++ b/src/protocol.h @@ -145,5 +145,6 @@ struct reply { #define NBD_ENOMEM 12 #define NBD_EINVAL 22 #define NBD_ENOSPC 28 +#define NBD_ESHUTDOWN 108 #endif /* NBDKIT_PROTOCOL_H */ -- 2...

...NO_HOLE` flag was present, or even on whether a + previous `NBD_CMD_TRIM` had been performed on the region. If the + server did not advertise `NBD_FLAG_SEND_FAST_ZERO`, then it SHOULD + NOT fail with `NBD_ENOTSUP`, regardless of the speed of servicing + a request, and SHOULD fail with `NBD_EINVAL` if the + `NBD_CMD_FLAG_FAST_ZERO` flag was set. A server MAY advertise + `NBD_FLAG_SEND_FAST_ZERO` whether or not it can perform fast + zeroing; similarly, a server SHOULD fail with `NBD_ENOTSUP` when + the flag is set if the server cannot quickly determine in advance + whether that...

...;2) +#define NBD_CMD_FLAG_REQ_ONE (1<<3) +#define NBD_CMD_FLAG_FAST_ZERO (1<<4) /* Error codes (previously errno). * See http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ca4414804114fd0095b317785bc0b51862e62ebb @@ -239,6 +241,7 @@ extern const char *name_of_nbd_error (int); #define NBD_EINVAL 22 #define NBD_ENOSPC 28 #define NBD_EOVERFLOW 75 +#define NBD_ENOTSUP 95 #define NBD_ESHUTDOWN 108 #endif /* NBDKIT_PROTOCOL_H */ diff --git a/server/filters.c b/server/filters.c index 14ca0cc6..0dd2393e 100644 --- a/server/filters.c +++ b/server/filters.c @@ -403,8 +403,11 @@ nex...

...ne NBD_FLAG_CAN_MULTI_CONN (1 << 8) #define NBD_FLAG_SEND_CACHE (1 << 10) +#define NBD_FLAG_SEND_FAST_ZERO (1 << 11) /* NBD options (new style handshake only). */ #define NBD_OPT_EXPORT_NAME 1 @@ -250,6 +251,7 @@ struct nbd_structured_reply_error { #define NBD_EINVAL 22 #define NBD_ENOSPC 28 #define NBD_EOVERFLOW 75 +#define NBD_ENOTSUP 95 #define NBD_ESHUTDOWN 108 #endif /* NBD_PROTOCOL_H */ diff --git a/generator/generator b/generator/generator index c509573..9b1f5d8 100755 --- a/generator/generator +++ b/generator/generator @@ -958,10 +958,1...

v2 was here: https://lists.debian.org/nbd/2022/11/msg00030.html The bulk of the changes since then are: - forbid NBD_OPT_EXPORT_NAME once extended headers are negotiated (Wouter) - consistently use 'maximum payload', rather than a haphazard mix of 'maximum block payload' (Vladimir) At this point, I want to make sure we are happy with the spec before re-posting patches for

...SEND_DF); +} + int nbd_unlocked_can_multi_conn (struct nbd_handle *h) { diff --git a/lib/nbd-protocol.h b/lib/nbd-protocol.h index 071971e..405af3e 100644 --- a/lib/nbd-protocol.h +++ b/lib/nbd-protocol.h @@ -245,6 +245,7 @@ struct nbd_structured_reply_error { #define NBD_ENOMEM 12 #define NBD_EINVAL 22 #define NBD_ENOSPC 28 +#define NBD_EOVERFLOW 75 #define NBD_ESHUTDOWN 108 #endif /* NBD_PROTOCOL_H */ diff --git a/lib/protocol.c b/lib/protocol.c index d3ac0b4..6087887 100644 --- a/lib/protocol.c +++ b/lib/protocol.c @@ -35,6 +35,7 @@ nbd_internal_errno_of_nbd_error (uint32_t erro...

...-0600, Eric Blake wrote: > Commit 9f30fedb improved the spec to allow non-payload requests that > exceed any advertised maximum block size. Take this one step further > by permitting the server to use NBD_EOVERFLOW as a hint to the client > when a request is oversize (while permitting NBD_EINVAL for > back-compat), and by rewording the text to explicitly call out that > what is being advertised is the maximum payload length, not maximum > block size. This becomes more important when we add 64-bit > extensions, where it becomes possible to extend `NBD_CMD_BLOCK_STATUS` > to...

..._errno (int error, bool flag_df) { switch (error) { case 0: @@ -349,7 +349,9 @@ nbd_errno (int error) return NBD_ESHUTDOWN; #endif case EOVERFLOW: - return NBD_EOVERFLOW; + if (flag_df) + return NBD_EOVERFLOW; + /* fallthrough */ case EINVAL: default: return NBD_EINVAL; @@ -368,7 +370,7 @@ send_simple_reply (struct connection *conn, reply.magic = htobe32 (NBD_SIMPLE_REPLY_MAGIC); reply.handle = handle; - reply.error = htobe32 (nbd_errno (error)); + reply.error = htobe32 (nbd_errno (error, false)); r = conn->send (conn, &reply, sizeof reply);...

...ENOTSUP; > > This may provoke returning NBD_ENOTSUP in other cases, not only new one we are going to add. Correct. But the spec only said SHOULD avoid ENOTSUP in those other cases, not MUST avoid ENOTSUP; and in practice, either the client that is not suspecting it will treat it the same as NBD_EINVAL, or we've managed to get a slightly better error message across than normal. I don't see that as a real show-stopper. But if it bothers you, note that in nbdkit, I actually coded things up to refuse to send NBD_EOVERFLOW unless NBD_CMD_FLAG_DF was set, and to refuse to send NBD_ENOTSUP un...

...rote: > > Commit 9f30fedb improved the spec to allow non-payload requests that > > exceed any advertised maximum block size. Take this one step further > > by permitting the server to use NBD_EOVERFLOW as a hint to the client > > when a request is oversize (while permitting NBD_EINVAL for > > back-compat), and by rewording the text to explicitly call out that > > what is being advertised is the maximum payload length, not maximum > > block size. This becomes more important when we add 64-bit > > extensions, where it becomes possible to extend `NBD_CMD_BL...

...nbd is used to trigger a protocol violation, it will still gracefully handle whatever the server may return (even if by disconnecting from the server). However, a flaw in the logic for validating block status responses meant that a server that does not follow the usual practice of replying with an NBD_EINVAL error to an unexpected command can crash libnbd with an assertion failure when libnbd is used to send an unexpected block status request, rather than the intended behavior of diagnosing the server's unusual response. Test if libnbd is vulnerable ---------------------------- As the crash can o...

I'm hoping to implement .extents for the nbd plugin; this is a prerequisite. I'm not sure about patch 3 - if we like it, I'll squash it to 2, if we don't, I think we are okay just dropping it. I'm also wondering if we have to worry about malicious plugins that don't populate the entire .pread buffer in an effort to get nbdkit to expose portions of the heap; my patch 7 loses

This is a cover letter to a series of patches being proposed in tandem to four different projects: - nbd: Document a new NBD_CMD_FLAG_FAST_ZERO command flag - qemu: Implement the flag for both clients and server - libnbd: Implement the flag for clients - nbdkit: Implement the flag for servers, including the nbd passthrough client If you want to test the patches together, I've pushed a

..._FLAG_PAYLOAD_LEN` flag and uses a *length* larger than +a server's advertised or default maximum payload length (capped at +32 bits by the constraints of `NBD_INFO_BLOCK_SIZE`); in all other +cases, a server SHOULD gracefully consume *length* bytes of payload +(even if it then replies with an `NBD_EINVAL` failure because the +particular command was not expecting a payload), and proceed with +the next client command. Thus, only when *length* is used as an +effective length will it utilize a full 64-bit value. + #### Simple reply message The simple reply message MUST be sent by the server in resp...

This fix isn't exhaustive but it fixes some obvious problems in the filters. Rich.

...n whether a >> + previous `NBD_CMD_TRIM` had been performed on the region. If the >> + server did not advertise `NBD_FLAG_SEND_FAST_ZERO`, then it SHOULD >> + NOT fail with `NBD_ENOTSUP`, regardless of the speed of servicing >> + a request, and SHOULD fail with `NBD_EINVAL` if the >> + `NBD_CMD_FLAG_FAST_ZERO` flag was set. A server MAY advertise >> + `NBD_FLAG_SEND_FAST_ZERO` whether or not it can perform fast >> + zeroing; similarly, a server SHOULD fail with `NBD_ENOTSUP` when >> + the flag is set if the server cannot quickly de...

On Tue, Apr 23, 2019 at 07:38:41AM -0500, Eric Blake wrote: > [adding NBD list] > > On 4/23/19 2:36 AM, Richard W.M. Jones wrote: > > On Mon, Apr 22, 2019 at 07:50:22PM -0500, Eric Blake wrote: > >> Previously, we were squashing EOVERFLOW into EINVAL; continue to do so > >> at points in the protocol where the client may not be expecting > >> EOVERFLOW.

...case 0: > @@ -349,7 +349,9 @@ nbd_errno (int error) > return NBD_ESHUTDOWN; > #endif > case EOVERFLOW: > - return NBD_EOVERFLOW; > + if (flag_df) > + return NBD_EOVERFLOW; > + /* fallthrough */ > case EINVAL: > default: > return NBD_EINVAL; > @@ -368,7 +370,7 @@ send_simple_reply (struct connection *conn, > > reply.magic = htobe32 (NBD_SIMPLE_REPLY_MAGIC); > reply.handle = handle; > - reply.error = htobe32 (nbd_errno (error)); > + reply.error = htobe32 (nbd_errno (error, false)); > > r = conn->...

...t handle *h, int *fd) case NBD_ENOMEM: return ENOMEM; default: - nbdkit_debug ("unexpected error %d, squashing to EINVAL", - be32toh (rep.error)); + nbdkit_debug ("unexpected error %d, squashing to EINVAL", error); /* fallthrough */ case NBD_EINVAL: return EINVAL; @@ -405,7 +570,9 @@ nbd_reader (void *handle) r = nbd_reply_raw (h, &fd); if (r >= 0) { - if (write (fd, &r, sizeof r) != sizeof r) { + if (fd < 0) + nbdkit_debug ("partial reply handled, waiting for final reply"); + else...

Fix some things I noticed while reviewing v1, and follow Rich's idea to add a new nbdkit_set_error() utility function with a binding for Python users to request a particular error (rather than being forced to live with whatever stale value is in errno after all the intermediate binding glue code). I could not easily find out how to register a C function callable from perl bindings, and have