similar to: [libnbd PATCH] tests: Enhance errors test

This might not be the final solution, but it certainly seems to solve a deadlock for me that I could trigger by using 'nbdkit --filter=noparallel memory 512k' and calling nbd_aio_pread for a request larger than 256k (enough for the Linux kernel to block the server until libnbd read()s), immediately followed by nbd_aio_pwrite for a request larger than 256k (enough to block libnbd until the

On Tue, May 30, 2023 at 04:06:32PM +0200, Laszlo Ersek wrote: > On 5/25/23 15:00, Eric Blake wrote: > > Support sending 64-bit requests if extended headers were negotiated. > > This includes setting NBD_CMD_FLAG_PAYLOAD_LEN any time we send an > > extended NBD_CMD_WRITE; this is such a fundamental part of the > > protocol that for now it is easier to silently ignore

On v1, we discussed whether cmds_to_issue needed to be a list, since it never had more than one element. I played with the idea of making it a list, and allowing the client to queue up new commands regardless of whether the state machine is currently in READY. I also polished up the tmp demo into a bit more full-fledged example file, worth including since it also let me discover a hard-to-hit race

Since v2: - rebase to Rich's new API calls - more refactoring in patch 1 (retitled) - new patches 3 and 4 - fix data corruption in patch 6 (was 4) - more tweaks to the reproducer example (including using new API from 3) Eric Blake (7): lib: Refactor command_common() to do more common work commands: Allow for a command queue commands: Expose FIFO ordering of server completions

When run under valgrind, the 'errors' test would sometimes fail because a single NBD_CMD_WRITE managed to actually send() the entire packet to the server without blocking the state machine. To make things more robust, switch to a server which is serialized (memory is parallel, but sh is serial), and which intentionally does not read a second command until the first is processed, then

On Thu, Jun 27, 2019 at 10:18:30PM -0500, Eric Blake wrote: > + /* Queue up a write command so large that we block on POLLIN, then queue > + * multiple disconnects. XXX The last one should fail. > + */ > + if (nbd_aio_pwrite (nbd, buf, 2 * 1024 * 1024, 0, 0) == -1) { > + fprintf (stderr, "%s: %s\n", argv[0], nbd_get_error ()); > + exit (EXIT_FAILURE); > +

Very much a work in progress as there are still many tests using qemu-io which are candidates for conversion. You'll notice at the end of test-full.sh that the new test has some duplicated code which looks as if it ought to be refactored into a Python function. When I tried to do that, I got loads of strange Python problems which may indicate bugs in nbdsh itself or problems with my

--- This is what I used to provoke the deadlocks; before my patch series, it was succeeding for a fully-parallel server: nbdkit -U - memory 2M --run './deadlock $unixsocket' as well as for a serialized server that didn't trip up Linux kernel buffering limits: nbdkit -U - --filter=noparallel memory 256k --run './deadlock $unixsocket' but was reliably hanging with both client

On 6/30/19 12:54 PM, Richard W.M. Jones wrote: > On Thu, Jun 27, 2019 at 10:18:30PM -0500, Eric Blake wrote: >> + /* Queue up a write command so large that we block on POLLIN, then queue >> + * multiple disconnects. XXX The last one should fail. >> + */ >> + if (nbd_aio_pwrite (nbd, buf, 2 * 1024 * 1024, 0, 0) == -1) { >> + fprintf (stderr, "%s:

As mentioned in commits 176fc4ea and 609c25f0, our original plan in adding a flags argument to nbd_shutdown was to let us specify different behaviors at the libnbd level, rather than NBD protocol flags (for that, the user has nbd_aio_disconnect). But when we later parameterized OFlags to accept various bitmasks (commit f891340b), we failed to mark nbd_shutdown as using a different bitmask than

The original nbd_aio_* (non-callback) functions are removed and replaced with the renamed callback variants. This is a simple mechanical change to the API: (1) Any existing call to nbd_aio_*_callback can simply be renamed to nbd_aio_* (2) Any existing call to nbd_aio_* must have two extra NULL parameters added before the final flags parameter. In non-C languages, only change (1) is

Added merely as an example to be run by hand, rather than automated into 'make check', since nbdkit --filter=noparallel is quite new. --- .gitignore | 1 + examples/Makefile.am | 10 ++ examples/batched-read-write.c | 214 ++++++++++++++++++++++++++++++++++ 3 files changed, 225 insertions(+) create mode 100644 examples/batched-read-write.c diff --git

On Wed, Sep 11, 2019 at 08:48:28AM -0500, Eric Blake wrote: > On 9/11/19 5:40 AM, Richard W.M. Jones wrote: > > Very much a work in progress as there are still many tests using > > qemu-io which are candidates for conversion. > > > > You'll notice at the end of test-full.sh that the new test has some > > duplicated code which looks as if it ought to be

Right now, libnbd has refused to issue a command not advertised as supported by a server, including unknown flags, mainly because the NBD protocol does not guarantee what the server will do, and libnbd would rather stay in sync with the server than drop the connection. However, for integration purposes, it can be handy to coerce libnbd into sending something to see how the server will react

This is a continuation of a discussion we were having on IRC. The problems with IRC are it's not recorded and it's hard to have deep technical conversations. I hope this is a decent summary. Problem simply stated: Certain NBD servers (qemu-nbd in particular) are able to simultaneously read and write on a socket. ie. They can be simultaneously reading a request and writing the reply to

This applies on top of the OClosure v2 series posted a few minutes ago. Rich.

On Fri, Sep 11, 2020 at 04:49:55PM -0500, Eric Blake wrote: > The next strict knob: allow the user to pass unknown flags across the > wire (this is different than passing a known flag at the wrong time). > > It is interesting to note that NBD only permits 16 bits of flags, but > we have a signature that takes uint32_t; if we wanted, we could pack > libnbd-specific flags in the

On 8/13/19 5:36 PM, Richard W.M. Jones wrote: > The definition of functions that take a callback is changed so that > the callback and user_data are combined into a single structure, eg: > > int64_t nbd_aio_pread (struct nbd_handle *h, > void *buf, size_t count, uint64_t offset, > - int (*completion_callback) (/*..*/), void *user_data, > +

The NBD protocol states that a 0-length request is undefined; we were inconsistent in that we let it through for read, write, and cache, but blocked it for trim, zero, and block_status. The NBD protocol also has documented rules on handling access beyond EOF, but we are currently wasting traffic to the server when we can give the same answer ourselves. Exposing this as a strictness knob gives

On Wed, Jun 19, 2019 at 09:11:52PM -0500, Eric Blake wrote: > When we are blocked waiting for POLLOUT during a request, and happen > to receive notice of POLLIN instead, we know that the work done in > response to POLLIN will be non-blocking (it returns to %.READY as soon > as it would block, which in turn jumps right back into ISSUE_COMMAND > because we have a pending request not