search for: issue_command

There were a few unchecked syscalls in fish.c >From ba8b8b0684a03b6e6fbb939ed7e1cbf5e1000092 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering at redhat.com> Date: Wed, 19 Aug 2009 10:01:07 +0200 Subject: [PATCH libguestfs] guestfish: detect a few more failed syscalls * fish/fish.c (issue_command): Detect/diagnose more failed syscalls. --- fish/fish.c | 26 +++++++++++++++++++++----- 1 files changed, 21 insertions(+), 5 deletions(-) diff --git a/fish/fish.c b/fish/fish.c index 830617b..e6cd270 100644 --- a/fish/fish.c +++ b/fish/fish.c @@ -750,8 +750,14 @@ issue_command (const char *cmd...

...++++++++++ generator/states-issue-command.c | 45 ++++++++++++++++++++------------ 2 files changed, 42 insertions(+), 17 deletions(-) diff --git a/generator/generator b/generator/generator index a1bf41d..a4ad362 100755 --- a/generator/generator +++ b/generator/generator @@ -637,12 +637,26 @@ and issue_command_state_machine = [ external_events = [ NotifyWrite, "" ]; }; + State { + default_state with + name = "PREPARE_WRITE_PAYLOAD"; + comment = "Prepare the write payload to send to the remote server"; + external_events = []; + }; + State { defa...

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

...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_COMMAND.PREPARE_WRITE_PAYLOAD - &g...

...uot;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_COMMAND.P...

...PLY -> 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_COMMAND.PREPARE_WRITE_PAYLOAD -&...

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

...was to allow a notifyread at any time we are in the middle of writing a request, at which point we pause the current write, force the state machine to completely receive the reply, then resume where we left off writing the request. Eric Blake (3): commands: Preserve FIFO ordering states: Split ISSUE_COMMAND.SEND_REQUEST states: Allow in-flight read while writing next command generator/generator | 34 +++++++++++++++- generator/states-issue-command.c | 68 ++++++++++++++++++++++++-------- generator/states-reply.c | 18 +++++++-- lib/internal.h | 1 + lib/rw.c...

...generator/states-reply.c | 5 ++++- lib/internal.h | 1 + 4 files changed, 47 insertions(+), 4 deletions(-) diff --git a/generator/generator b/generator/generator index a4ad362..23b3cbf 100755 --- a/generator/generator +++ b/generator/generator @@ -634,7 +634,15 @@ and issue_command_state_machine = [ default_state with name = "SEND_REQUEST"; comment = "Sending a request to the remote server"; - external_events = [ NotifyWrite, "" ]; + external_events = [ NotifyWrite, ""; + NotifyRead, "PAU...

...sue-command.c | 25 ++++++++++++++++++++++++- lib/internal.h | 1 + 3 files changed, 43 insertions(+), 9 deletions(-) diff --git a/generator/generator b/generator/generator index a4ad362..5c84a5d 100755 --- a/generator/generator +++ b/generator/generator @@ -620,12 +620,6 @@ and issue_command_state_machine = [ State { default_state with name = "START"; - (* XXX There's a possible deadlock here if a server cannot - * handle multiple requests pipelined on a single connection. - * We could try to issue a command and block, but reads might - * be av...

...yright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==11953== For more details, rerun with: -v ==11953== ==11953== Invalid read of size 2 ==11953== at 0x3E89C6653D: fflush (in /lib64/libc-2.10.1.so) ==11953== by 0x415E26: rc_remote (rc.c:269) ==11953== by 0x413C53: issue_command (fish.c:779) ==11953== by 0x414F81: main (fish.c:721) ==11953== Address 0x4e602e8 is 0 bytes inside a block of size 568 free'd ==11953== at 0x4A0633D: free (vg_replace_malloc.c:323) ==11953== by 0x3E89C660DC: fclose@@GLIBC_2.2.5 (in /lib64/libc-2.10.1.so) ==11953== by 0x4...

...p the tmp demo into a bit more full-fledged example file, worth including since it also let me discover a hard-to-hit race with large NBD_CMD_WRITE vs. EAGAIN failures (now fixed). Eric Blake (5): lib: Refactor state event into command_common commands: Allow for a command queue states: Split ISSUE_COMMAND.SEND_REQUEST states: Allow in-flight read while writing next command examples: Add example to demonstrate just-fixed deadlock scenario .gitignore | 1 + examples/Makefile.am | 10 ++ examples/batched-read-write.c | 199 +++++++++++++++++++++++++++++++ g...

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

...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 disconnect: Allow shutdown during processing states: Split ISSUE_COMMAND.SEND_REQUEST states: Allow in-flight read while writing next command examples: Add example to demonstrate just-fixed deadlock scenario .gitignore | 1 + examples/Makefile.am | 10 ++ examples/batched-read-write.c | 214 +++++++++++++++++++++++++++++++ g...

...drained), so I'm not sure if the algorithmic complexity reaches the > point where it will matter. Actually commands _are_ issued in order. 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 c...

...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 fully sent yet). Since the > jaunt through REPLY was non-blocking, it is unlikely that the POLLOUT > situation has changed in the meantime, so if we use SET_NEXT_STATE() > to step back into SEND_REQUEST, our recv() call will likely fail with >...

...URE); > +} > + > +/* Execute a command in the background, sending output to a pipe. */ > +static int > +bg_command (char **argv, char **pipef) > +{ Reading this and other similar implementations, for example: - fish/events.c, do_event_handler - fish/fish.c, execute_and_inline and issue_command (which has a comment regarding pipe commands) - src/command.c, run_command - src/launch-direct.c, launch_direct - src/launch-uml.c, launch_uml - daemon/guestfsd.c, commandrf (maybe, since it is in the appliance); other popen usages in daemon/* what about using libpipeline [1] to handle them? W...

...tfs_impl_launch (g=g@entry=0x7fe6f8e04bd0) at launch.c:93 #7 0x00007fe6f790fb4d in guestfs_launch (g=0x7fe6f8e04bd0) at actions-3.c:142 #8 0x00007fe6f86e7eda in run_launch (cmd=<optimized out>, argc=<optimized out>, argv=<optimized out>) at cmds.c:13411 #9 0x00007fe6f870276c in issue_command (cmd=0x7fe6f8df5170 "run", argv=argv@entry=0x7ffe4c053f98, pipecmd=0x0, rc_exit_on_error_flag=<optimized out>) at fish.c:1181 #10 0x00007fe6f870334e in script (prompt=prompt@entry=1) at fish.c:733 #11 0x00007fe6f86c7262 in interactive () at fish.c:630 #12 main (argc=1, argv=0x7ffe4c...

...nbdkit -U - --filter=noparallel memory 256k --run './deadlock $unixsocket' but was reliably hanging with both client and server on larger buffers: nbdkit -U - --filter=noparallel memory 512k --run './deadlock $unixsocket' Post-patch, you can see the state machine now shift through ISSUE_COMMAND.PAUSE_WRITE_PAYLOAD through an entire REPLY.START..REPLY.FINISH sequence, and then resume in the middle of the ISSUE_COMMAND.SEND_WRITE_PAYLOAD. .gitignore | 1 + examples/Makefile.am | 10 +++ examples/deadlock.c | 200 +++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 2...

nbdkit 1.2 as a server waits for read() to see EOF, even after the client has sent NBD_CMD_DISC. That was fixed in mbdkit 1.4; and most modern NBD servers are smarter than this (they close() the write end of their traffic soon after NBD_CMD_DISC). But it's easy enough to revert nbdkit commit c70616f8 to get back to a server with the same behavior as the older nbdkit, at which point both