search for: nbd_cmd_read

...a maximum offset in nbdkit_extents in patch 1, this may be picked up automatically) > @@ -498,15 +605,23 @@ protocol_recv_request_send_reply (struct connection *conn) > } > > /* Currently we prefer to send simple replies for everything except > - * where we have to (ie. NBD_CMD_READ when structured_replies have > - * been negotiated). However this prevents us from sending > - * human-readable error messages to the client, so we should > - * reconsider this in future. > + * where we have to (ie. NBD_CMD_READ and NBD_CMD_BLOCK_STATUS when > + * structur...

When facing a malicious client that is sending bogus NBD_CMD_READ, we should make sure that we never end up in a situation where we could try to treat the tail from a command that we diagnosed as bad as being further commands. Eric Blake (2): connections: Report mid-message EOF as fatal connections: Hang up early on insanely large WRITE requests src/connec...

On 12/6/18 3:50 PM, Richard W.M. Jones wrote: > This generates small functions which map from various integer NBD > protocol flags to the string equivalent. > > eg: > name_of_nbd_cmd (NBD_CMD_READ) > ---> "NBD_CMD_READ" > > This commit uses some hairy sed scripting to ensure that we don't add > any more dependencies to nbdkit. Hairy, but well-commented. It forces some rather strict formatting to keep things working, but we touch the file seldom enough t...

With some crufty sed scripts we can generate functions that map from NBD protocol flags (eg. NBD_CMD_READ) to strings ("NBD_CMD_READ"). This works on GNU sed and with FreeBSD, also with GNU sed's --posix option, so I guess the sed code is POSIX-compatible. Rich.

...one is patch 3 which fixes a protocol violation that makes it impossible for a client to try and recover from EIO failures over a partially-flaky source block device. Eric Blake (3): maint: Add emacs hint file maint: Add NBDKIT_GDB support to in-tree nbdkit script connections: Don't send NBD_CMD_READ payload on error .dir-locals.el | 1 + nbdkit.in | 9 +++++++-- src/connections.c | 2 +- 3 files changed, 9 insertions(+), 3 deletions(-) create mode 100644 .dir-locals.el -- 2.13.6

...} SET_NEXT_STATE (%^FINISH_COMMAND); diff --git a/generator/states-reply-structured.c b/generator/states-reply-structured.c index 2e327ce..58e83d4 100644 --- a/generator/states-reply-structured.c +++ b/generator/states-reply-structured.c @@ -295,7 +295,6 @@ } if (cmd->type == NBD_CMD_READ && cmd->cb.fn.chunk.callback) { int scratch = error; - uint16_t flags = be16toh (h->sbuf.sr.structured_reply.flags); /* Different from successful reads: inform the callback about the * current error rather than any earlier one. If the callback fails...

This is about the simplest implementation of NBD Structured Replies (SR) that we can do right now. It accepts NBD_OPT_STRUCTURED_REPLIES when negotiated by the client, but only sends back the simplest possible SR when required to by NBD_CMD_READ. The rest of the time it will send back simple replies as before. We do not modify the plugin API so plugins are unable to send complex SRs. Also we do not handle human-readable error messages yet because that would require changes in how we handle nbdkit_error(). Also we do not understand NBD_...

...ompute which reply is current. This also consolidates the logic when a reply has an unexpected handle - previously, we failed for structured (even though the length makes it easy to recover) and passed for simple (even though there is nothing on the wire to state if this response is associated with NBD_CMD_READ if we did not negotiate structured replies, which would allow our state machine to start parsing arbitrary data as new responses); we're better off just always moving to DEAD. --- generator/states-reply-simple.c | 15 ++----- generator/states-reply-structured.c | 61 ++++++-----------------...

...on *conn) uint32_t magic, count, error = 0; uint64_t offset; CLEANUP_FREE char *buf = NULL; + CLEANUP_EXTENTS_FREE struct nbdkit_extents *extents = NULL; /* Read the request packet. */ { @@ -449,6 +548,7 @@ protocol_recv_request_send_reply (struct connection *conn) if (cmd == NBD_CMD_READ || cmd == NBD_CMD_WRITE) { buf = malloc (count); if (buf == NULL) { + out_of_memory: perror ("malloc"); error = ENOMEM; if (cmd == NBD_CMD_WRITE && @@ -458,6 +558,13 @@ protocol_recv_request_send_reply (struct connection *conn)...

...s you would end up registering thousands of > close callbacks. > > +++ b/lib/aio.c > @@ -90,6 +90,17 @@ nbd_unlocked_aio_command_completed (struct nbd_handle *h, > else > h->cmds_done = cmd->next; > > + /* Free the callbacks. */ > + if (cmd->type != NBD_CMD_READ && cmd->cb.fn.extent) > + cmd->cb.fn.extent (LIBNBD_CALLBACK_FREE, cmd->cb.fn_user_data, > + NULL, 0, NULL, 0, NULL); > + if (cmd->type == NBD_CMD_READ && cmd->cb.fn.read) > + cmd->cb.fn.read (LIBNBD_CALLBACK_FREE, cmd->c...

....sr.structured_reply.flags); if (flags & NBD_REPLY_FLAG_DONE) { - if (cmd->type == NBD_CMD_BLOCK_STATUS && cmd->cb.fn.extent.callback) { - if (cmd->cb.fn.extent.free) - cmd->cb.fn.extent.free (cmd->cb.fn.extent.user_data); - } - if (cmd->type == NBD_CMD_READ && cmd->cb.fn.chunk.callback) { - if (cmd->cb.fn.chunk.free) - cmd->cb.fn.chunk.free (cmd->cb.fn.chunk.user_data); - } - cmd->cb.fn.extent.callback = NULL; - cmd->cb.fn.chunk.callback = NULL; + if (cmd->type == NBD_CMD_BLOCK_STATUS) + FREE_C...

Rather than requiring all servers and clients to have a 32-bit limit on maximum NBD_CMD_READ/WRITE sizes, we can choose to standardize support for a 64-bit single I/O transaction now. NBD_REPLY_TYPE_OFFSET_DATA can already handle a large reply, but NBD_REPLY_TYPE_OFFSET_HOLE needs a 64-bit counterpart. By standardizing this, all clients must be prepared to support both types of hole type...

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

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. > > Signed-off-by: Eric Blake <eblake@redhat.com> > --- > server/protocol.c | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) >

...buf = NULL; + CLEANUP_EXTENTS_FREE struct nbdkit_extents_map *extents_map = NULL; + CLEANUP_FREE struct block_descriptor *blocks = NULL; + size_t nr_blocks = 0; /* Read the request packet. */ { @@ -449,6 +637,7 @@ protocol_recv_request_send_reply (struct connection *conn) if (cmd == NBD_CMD_READ || cmd == NBD_CMD_WRITE) { buf = malloc (count); if (buf == NULL) { + out_of_memory: perror ("malloc"); error = ENOMEM; if (cmd == NBD_CMD_WRITE && @@ -458,6 +647,13 @@ protocol_recv_request_send_reply (struct connection *conn)...

...MMAND); > diff --git a/generator/states-reply-structured.c b/generator/states-reply-structured.c > index 2e327ce..58e83d4 100644 > --- a/generator/states-reply-structured.c > +++ b/generator/states-reply-structured.c > @@ -295,7 +295,6 @@ > } > if (cmd->type == NBD_CMD_READ && cmd->cb.fn.chunk.callback) { > int scratch = error; > - uint16_t flags = be16toh (h->sbuf.sr.structured_reply.flags); > > /* Different from successful reads: inform the callback about the > * current error rather than any earlier o...

The DF flag is only available to clients that negotiated structured replies, and even then, the spec does not require that it be implemented. However, since our current implementation can't fragment NBD_CMD_READ replies, we trivially implement the flag (by ignoring it); we don't even have to pass it on to the plugins. Enhance some documentation about sparse reads while at it (when we finally do allow plugins to implement sparse reads, we'll have to pass on the DF flag, as well as perform reassembl...

...it: pattern.1: error: injecting EIO error into pread nbdkit: pattern.1: debug: sending error reply: Input/output error nbdkit: pattern.3: debug: error-inject: pread count=262144 offset=4980736 nbdkit: pattern.3: debug: pattern: pread count=262144 offset=4980736 nbdkit: pattern.4: error: write data: NBD_CMD_READ: Broken pipe nbdkit: pattern.4: debug: exiting worker thread pattern.4 nbdkit: connections.c:402: raw_send_socket: Assertion `sock >= 0' failed. When there are multiple queued requests, and the client hangs up abruptly as soon as the first error response is seen (rather than waiting until a...

...ions(+) > > diff --git a/generator/states-reply-simple.c b/generator/states-reply-simple.c > index 12536e0..935f6d2 100644 > --- a/generator/states-reply-simple.c > +++ b/generator/states-reply-simple.c > @@ -40,6 +40,7 @@ > if (cmd->error == 0 && cmd->type == NBD_CMD_READ) { > h->rbuf = cmd->data; > h->rlen = cmd->count; > + cmd->data_seen = true; > SET_NEXT_STATE (%RECV_READ_PAYLOAD); > } > else { > diff --git a/generator/states-reply-structured.c b/generator/states-reply-structured.c > index 9bb165b..6...

...new negotiation feature where the client and server agree to use larger packet headers on every packet sent during transmission phase. This has two purposes: first, it makes it possible to perform operations like trim, write zeroes, and block status on more than 2^32 bytes in a single command. For NBD_CMD_READ, replies are still implicitly capped by the maximum block payload limits (generally 32M); if you want to know if a hole larger than 32 bits can represent, you'll use BLOCK_STATUS instead of hoping that a large READ will either return a hole or report overflow. But for NBD_CMD_BLOCK_STATUS, it...