similar to: [PATCH] lib: avoid pragma usage in journal.c

On 4/22/19 7:50 PM, Eric Blake wrote: > Time to enhance the nbd plugin to request structured replies from the > server. For now, deal only with structured reads. The server can now > return sparse reads, even though we need nbdkit version 3 before we > can in turn return sparse reads back to the client. > > In general, we have to assume the server is malicious, and so we must

Two simple build fixes for libldm. Well, the first isn't a build fix as such, but a code improvement. Rich.

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

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

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

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

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 +++

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):

The NBD spec was recently patched (nbd.git commit 7827f3ae and friends) to require NBD_OPT_GO for baseline interoperability, with the aim of fewer servers and clients falling back to NBD_OPT_EXPORT_NAME. And since nbdkit as server recently started supporting NBD_OPT_GO (commit f7dd9799), our nbd client as plugin should take advantage of it. This patch is a prerequisite to teaching the nbd plugin

If the server passes us a malformed error reply type with a message length longer than the overall structured reply, we would blindly obey that size and get out of sync with the server (perhaps even hanging on a read for data that will never come). Broken since its introduction in commit 28952eda. Fix it by parsing the tail of an error separate from the message, which also lets us add other

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 +++----------

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

pragma GCC diagnostic is a gcc 4.6+ feature, compilation fails with older compilers: inspect-fs-windows.c: In function 'map_registry_disk_blob': inspect-fs-windows.c:502: error: #pragma GCC diagnostic not allowed inside functions inspect-fs-windows.c:503: error: #pragma GCC diagnostic not allowed inside functions inspect-fs-windows.c:505: error: #pragma GCC diagnostic not allowed inside

Per recent discussion here: https://www.redhat.com/archives/libguestfs/2019-May/thread.html#00175

More nbd-protocol.h improvements Eric Blake (2): common/protocol: Switch nbdmagic to uint64_t common/protocol: Declare additional constants common/protocol/nbd-protocol.h | 16 ++++++++++------ server/protocol-handshake-newstyle.c | 2 +- server/protocol-handshake-oldstyle.c | 2 +- plugins/nbd/nbd-standalone.c | 2 +- tests/test-layers.c | 2 +- 5 files

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

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

In order to handle reading an in-flight response while in the middle of sending a second command, we'll need a way to jump back into the middle of a command being sent. This is easier if the state that sets wbuf is distinct from the state that reads into wbuf, and if we don't move the command to the in-flight queue until after the writes finish. --- generator/generator | 14

Fuzzing with afl found a bug where a 27 byte client sequence can cause nbdkit to report a strange error message: $ printf %s $'000\1IHAVEOPT000\6'$'000\7'$'000\1x00' | tr 0 '\0' | ./nbdkit -s memory size=1m >/dev/null nbdkit: memory: error: client exceeded maximum number of options (32) The culprit? The client is hanging up on a message boundary, so

https://bugzilla.netfilter.org/show_bug.cgi?id=891 Summary: Build failure on Slackware AMD 64bit with GLIBC 2.7 Product: ipset Version: unspecified Platform: x86_64 OS/Version: other Status: NEW Severity: trivial Priority: P5 Component: default AssignedTo: netfilter-buglog at lists.netfilter.org