search for: cmdissu

On 5/21/19 10:09 AM, Eric Blake wrote: > A generic client exploiting multiple in-flight commands should be > prepared for out-of-order responses (and should probably ensure that > there are no overlaps between parallel in-flight commands to avoid > unspecified disk contents if the server acts on commands in an > arbitrary order or even exposing non-atomic splicing effects). But a

...type external_event = | CmdConnectTCP (* [nbd_aio_connect_tcp] *) | CmdConnectCommand (* [nbd_aio_connect_command] *) | CmdConnectSA (* [nbd_aio_connect_systemd_socket_activation]*) + | CmdConnectSocket (* [nbd_aio_connect_socket] *) | CmdIssue (* issuing an NBD command *) type location = string * int (* source location: file, line number *) @@ -170,7 +171,8 @@ let rec state_machine = [ CmdConnectUnix, "CONNECT_UNIX.START"; CmdConnectTCP, "CONNECT_T...

...expecting a notify_read() are the same as setting an IRQ mask > that we don't want to be interrupted by a a read notification yet, but > we don't want to lose the interrupt when we later clear the mask) Yes, I think this is a good idea, and not difficult to implement. > In fact, CmdIssue is somewhat already like this - the code determines if > the state machine is unmasked (in the READY state) to kick it off > immediately; or is masked (in a processing state) to queue things but > leave the interrupt set (the next time we enter READY, we unmask, > observe the queue is...

...The reason is not obvious though! It's because cmds_to_issue shouldn't be a list at all. The handle lock is held while we move straight into ISSUE_COMMAND.START which moves the command to the in-flight list without blocking. Note also: The READY state has a permitted external transition CmdIssue -> ISSUE_COMMAND.START. Furthermore no other state has a CmdIssue external transition, and the generated code in the state machine will ensure that we can never CmdIssue in any other state. If my reasoning there is correct, we could simplify this patch by changing cmds_to_issue to be a single...

...+95,7 @@ type external_event = | CmdConnectUnix (* [nbd_aio_connect_unix] *) | CmdConnectTCP (* [nbd_aio_connect_tcp] *) | CmdConnectCommand (* [nbd_aio_connect_command] *) + | CmdConnectSA (* [nbd_aio_connect_socket_activation] *) | CmdIssue (* issuing an NBD command *) type location = string * int (* source location: file, line number *) @@ -168,13 +169,15 @@ let rec state_machine = [ CmdConnectSockAddr, "CONNECT.START"; CmdConnectUnix, "CONNECT...

...he call out-right for being in the wrong state. (That is, states where we are NOT expecting a notify_read() are the same as setting an IRQ mask that we don't want to be interrupted by a a read notification yet, but we don't want to lose the interrupt when we later clear the mask) In fact, CmdIssue is somewhat already like this - the code determines if the state machine is unmasked (in the READY state) to kick it off immediately; or is masked (in a processing state) to queue things but leave the interrupt set (the next time we enter READY, we unmask, observe the queue is non-empty, and so fi...

...+95,7 @@ type external_event = | CmdConnectUnix (* [nbd_aio_connect_unix] *) | CmdConnectTCP (* [nbd_aio_connect_tcp] *) | CmdConnectCommand (* [nbd_aio_connect_command] *) + | CmdConnectSA (* [nbd_aio_connect_socket_activation] *) | CmdIssue (* issuing an NBD command *) type location = string * int (* source location: file, line number *) @@ -168,13 +169,15 @@ let rec state_machine = [ CmdConnectSockAddr, "CONNECT.START"; CmdConnectUnix, "CONNECT...

For commands with long names and/or short descriptors, you can end up going over 72 characters in the first line of the man page (causing podwrapper to complain). Wrap these lines. --- generator/generator | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/generator/generator b/generator/generator index 7d3f656..ad1cb6b 100755 --- a/generator/generator +++ b/generator/generator

If the user calls nbd_kill_subprocess, we shouldn't kill the process again when we close the handle (since the process has likely gone and we might be killing a different process). --- lib/handle.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/handle.c b/lib/handle.c index 2af25fe..5ad818e 100644 --- a/lib/handle.c +++ b/lib/handle.c @@ -315,6 +315,8 @@

v1 was posted here: https://www.redhat.com/archives/libguestfs/2019-September/thread.html#00337 v2: - Drop the first patch. - Hopefully fix the multiple issues with fork-safety and general behaviour on error paths. Note this requires execvpe for which there seems to be no equivalent on FreeBSD, except some kind of tedious path parsing (but can we assign to environ?) Rich.

...so far. @@ -3151,7 +3196,7 @@ end = struct let all_external_events = [NotifyRead; NotifyWrite; CmdCreate; - CmdConnectSockAddr; CmdConnectUnix; CmdConnectTCP; + CmdConnectSockAddr; CmdConnectUnix; CmdConnectVSock; CmdConnectTCP; CmdConnectCommand; CmdConnectSA; CmdConnectSocket; CmdIssue] @@ -3161,6 +3206,7 @@ let string_of_external_event = function | CmdCreate -> "CmdCreate" | CmdConnectSockAddr -> "CmdConnectSockAddr" | CmdConnectUnix -> "CmdConnectUnix" + | CmdConnectVSock -> "CmdConnectVSock" | CmdConnectTCP -&...

Let's check for a quite a few more errors. Among other things, this adds some coverage for a few things I've patched recently. --- And these enhancements set me up for my next fix: making NBD_CMD_DISC prevent future commands. tests/errors.c | 167 +++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 154 insertions(+), 13 deletions(-) diff --git a/tests/errors.c

...stderr, "%s: test failed: " > + "expect to be blocked on write\n", > + argv[0]); > + exit (EXIT_FAILURE); > + } This test fails when run under valgrind. An abbreviated log shows what's happening: libnbd: debug: nbd_aio_pwrite: event CmdIssue: READY -> ISSUE_COMMAND.START libnbd: debug: nbd_aio_pwrite: transition: ISSUE_COMMAND.START -> ISSUE_COMMAND. SEND_REQUEST libnbd: debug: nbd_aio_pwrite: transition: ISSUE_COMMAND.SEND_REQUEST -> ISSUE_C OMMAND.PREPARE_WRITE_PAYLOAD libnbd: debug: nbd_aio_pwrite: transition: ISSUE_COMMAN...

...;> + "expect to be blocked on write\n", >> + argv[0]); >> + exit (EXIT_FAILURE); >> + } > > This test fails when run under valgrind. An abbreviated log shows > what's happening: > > libnbd: debug: nbd_aio_pwrite: event CmdIssue: READY -> ISSUE_COMMAND.START > libnbd: debug: nbd_aio_pwrite: transition: ISSUE_COMMAND.START -> ISSUE_COMMAND. > SEND_REQUEST > libnbd: debug: nbd_aio_pwrite: transition: ISSUE_COMMAND.SEND_REQUEST -> ISSUE_C > OMMAND.PREPARE_WRITE_PAYLOAD > libnbd: debug: nbd_aio_pwrite:...

...WSTYLE.OPT_GO.CHECK_REPLY -> READY libnbd: debug: nbd5: nbd_connect_uri: leave: ret=0 nbdkit: debug: starting worker thread full.0 nbdkit: debug: libnbd: debug: nbd5: nbd_pread: enter: buf=<buf> count=512 offset=0 flags=0x0 starting worker thread full.1libnbd: debug: nbd5: nbd_pread: event CmdIssue: READY -> ISSUE_COMMAND.START libnbd: debug: nbd5: nbd_pread: transition: ISSUE_COMMAND.START -> ISSUE_COMMAND.SEND_REQUEST libnbd: debug: nbd5: nbd_pread: transition: ISSUE_COMMAND.SEND_REQUEST -> ISSUE_COMMAND.PREPARE_WRITE_PAYLOAD libnbd: debug: nbd5: nbd_pread: transition: ISSUE_COMM...

This is a series of patches to libnbd and nbdkit adding AF_VSOCK support. On the host side it allows you to start an nbdkit instance which listens on a virtio-vsock socket: $ ./nbdkit -fv --vsock memory 1G ... nbdkit: debug: bound to vsock 2:10809 On the guest side you can then use libnbd to connect to the server: $ ./run nbdsh -c 'h.connect_vsock(2, 10809)' -c

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

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 dependence on the server's progress. The solution is similar to commit dd101bde - any time we need to pause the reply cycle, we need to save enough information to rec...

..._machine = [ Group ("OLDSTYLE", oldstyle_state_machine); Group ("NEWSTYLE", newstyle_state_machine); + State { + default_state with + name = "NEGOTIATING"; + comment = "Connection is ready to negotiate an NBD option"; + external_events = [ CmdIssue, "NEWSTYLE.START" ]; + }; + State { default_state with name = "READY"; @@ -271,6 +278,8 @@ and newstyle_state_machine = [ (* Options. These state groups are always entered unconditionally, * in this order. The START state in each group will check if the...

I need to think about this patch series a bit more, but it does at least pass the tests. Rich.