similar to: [libnbd PATCH] states: Validate error message size

On 6/9/23 04:17, Eric Blake wrote: > In order to more easily add a third reply type with an even larger > header, but where the payload will look the same for both structured > and extended replies, it is nicer if simple and structured replies are > nested inside the same layer of sbuf.reply.hdr. Doing this also lets > us add an alias for accessing the cookie directly without

When processing a server reply within the REPLY subgroup, we will often hit a situation where recv() requires us to block until the next NotifyRead. But since NotifyRead is the only permitted external action while in this group, we are effectively blocking CmdIssue and NotifyWrite events from happening until the server finishes the in-progress reply, even though those events have no strict

This was v3 patch 2/22, reworked to address the confusion about how a structured reply header is read in two pieces before getting to the payload portion. I'm still working on rebasing the rest of my v3 series (patches 1, 3-22) from other comments given, but this seemed independent enough that it's worth posting now rather than holding it up for the rest of the series. Eric Blake (4):

On Wed, Jun 19, 2019 at 01:18:01PM -0500, Eric Blake wrote: > Oddly enough, I am not getting any measurable performance difference > with this patch applied and using examples/threaded-reads-and-writes > coupled with nbdkit. My explanation is that in the common case, once > a server has something to send, it is going to send the entire reply > as fast as it can, rather than sending

Rather than repeating the logic for checking flags at multiple sites, stick it in a new state. --- generator/generator | 7 +++++ generator/states-reply-structured.c | 43 ++++++++++------------------- 2 files changed, 22 insertions(+), 28 deletions(-) diff --git a/generator/generator b/generator/generator index a289741..4c81859 100755 --- a/generator/generator +++

No need to have each state recompute 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

When we introduced valid_flags, there was an incentive to do as few callbacks as possible, favoring cb(VALID|FREE) calls over the sequence cb(VALID);cb(FREE). To make it work, we set .callback=NULL after an early free, so that the later check during retirement didn't free again. But now that our .free callback is distinct from our other callbacks, there is no longer an advantage to bundling

I'm still playing with ideas on how to split rstate from wstate (so that we can send a request without waiting for POLLIN to complete a pending reply), but this is some preliminary refactoring I found useful. I also fixed a couple of bugs while in the area (already pushed). There's a question of whether we want nbd_handle to be nearly 5k, or if we should instead keep it small and add one

Most of the states were calling SET_NEXT_STATE(%.DEAD) then using return -1 on error, to reflect the fact that they had also called set_error() and wanted the caller to notice the failure. Unfortunately, the state machine engine refuses to run the entry code of the next state when the current state returned -1, which meant the DEAD state entry code never runs. A concrete example of the problems

I've mentioned this topic before (in fact, the idea of adding NBD_CMD_FLAG_DF was first mentioned at [1]), but finally finished enough of an implementation to feel confident in posting it. I'd still like to add something under examples/ that uses the new API to implement strict checking of a server's structured replies read implementation (ensure that a server never sends data after

This isn't quite finished because not all of the tests or examples have been updated, but it demonstrates an idea: Should we forget about the concept of having multiple connections managed under a single handle? In this patch there is a single ‘struct nbd_handle *’ which manages a single state machine and connection (and therefore no nbd_connection). To connect to a multi-conn server you must

On Wed, Aug 14, 2019 at 05:38:31PM -0500, Eric Blake wrote: > When we introduced valid_flags, there was an incentive to do as few > callbacks as possible, favoring cb(VALID|FREE) calls over the sequence > cb(VALID);cb(FREE). To make it work, we set .callback=NULL after an > early free, so that the later check during retirement didn't free > again. > > But now that our

When a server supports structured reads, knowing where the holes are in the responses can aid the client's behavior. Furthermore, since the server can send data out of order or interleaved with other replies, a client may be able to start operating on the partial results as soon as they are available rather than waiting for the entire buffer to be reconstructed. As such, it makes sense to

Instead of repeating a check for valid reply headers in each sub-state machine, let's have a common helper function do all the work. Additionally, a central location will make it easier to uniformly capture any NBD_REP_ERR message payloads. --- generator/generator | 8 +-- generator/states-newstyle-opt-go.c | 40 +++----------

When we moved to an enum instead of raw int for nbd_set_tls(), we should have also updated our code to prefer the enum values. While at it, improve the grammar of error messages (confusing since 632196ec, and copy-and-pasted into more locations since then). Fixes: 4488cf2a Thanks: Rich Jones --- Rich noticed this while reviewing the patch for today's CVE fix. It's not a show-stopper if

Similar to the recent --mask-handshake command line added to nbdkit to test client fallbacks to crippled servers, it can be worth testing server fallbacks to crippled clients. And just as we have exposed whether the client will request structured replies, we can also expose whether the client will understand various handshake flags from the NBD protocol. Of course, we default to supporting all

Used both for servers that are not fixed newstyle, and for servers that don't understand NBD_OPT_GO. --- generator/Makefile.am | 1 + generator/generator | 39 +++++++++++ generator/states-newstyle-opt-export-name.c | 73 +++++++++++++++++++++ generator/states-newstyle-opt-go.c | 8 +-- generator/states-newstyle.c | 11

When a server supports structured reads, knowing where the holes are in the responses can aid the client's behavior. Furthermore, since the server can send data out of order or interleaved with other replies, a client may be able to start operating on the partial results as soon as they are available rather than waiting for the entire buffer to be reconstructed. As such, it makes sense to

When the server sets NBD_REPLY_FLAG_DONE on a data or block status chunk, we can use that fact to pass (VALID|FREE) and avoid a separate callback later just for FREE. --- As I've been promising in other threads... generator/states-reply-structured.c | 33 +++++++++++++++++++++++++---- 1 file changed, 29 insertions(+), 4 deletions(-) diff --git a/generator/states-reply-structured.c

Simple refactoring. --- generator/states-newstyle-opt-export-name.c | 12 +++++------ generator/states-newstyle-opt-go.c | 13 ++++++------ generator/states-oldstyle.c | 10 +++------- lib/flags.c | 22 +++++++++++++++++++++ lib/internal.h | 5 +++++ 5 files changed, 42 insertions(+), 20 deletions(-) diff