similar to: [libnbd PATCH] docs: Improve nbd_aio_get_direction documentation

On 5/31/19 11:01 AM, Richard W.M. Jones wrote: > 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) Also nbdkit for a plugin with

Since Eric's improvements to the command queue in commit 6af72b8 (and following) there's now a queue of commands waiting to be issued stored in the handle, and there's no need to issue commands only from the ready state. We can therefore remove the want_to_send logic, queue as many commands as possible, and don't need to test if the socket is ready for POLLOUT. This commit also

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

Make nbd_poll slightly more like poll(), allowing a user to detect timeouts by returning 0 on timeout and 1 when we made progress. It turns out that none of our internal uses ever expect a timeout (we only call nbd_internal_poll with timeout==-1 because we expect a reply from the server), but the public function might as well be nicer. Also handle POLLERR (server closed its read end, so our

It is necessary to kick the state machine any time another thread blocks due to write() encountering a full buffer, to get the reader thread to learn that it must now poll on POLLOUT rather than just POLLIN. POSIX only provides two ways to do this: either poll() on a second fd (our pipe-to-self trick), or interrupt the polling with EINTR due to delivery of a signal. So, I played with the latter

On 6/20/19 6:50 AM, Eric Blake wrote: > Mention things to remember for avoiding the deadlock of polling for a > POLLIN from a server that has no replies to send. > > Perhaps we could split the READY state into two - one for when there > are no commands in flight (and get_direction returns 0 to state that > polling is pointless, although a multi-threaded reader can still poll

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

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

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

--- .gitignore | 1 + examples/Makefile.am | 12 + examples/concurrent-writer.c | 450 +++++++++++++++++++++++++++ examples/threaded-reads-and-writes.c | 2 +- 4 files changed, 464 insertions(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index 30438c1..e4dad91 100644 --- a/.gitignore +++ b/.gitignore @@ -41,6 +41,7 @@ Makefile.in

--- .gitignore | 1 + examples/Makefile.am | 12 + examples/concurrent-writer.c | 450 +++++++++++++++++++++++++++++++++++ 3 files changed, 463 insertions(+) diff --git a/.gitignore b/.gitignore index 30438c1..e4dad91 100644 --- a/.gitignore +++ b/.gitignore @@ -41,6 +41,7 @@ Makefile.in /docs/libnbd-api.3 /docs/libnbd-api.pod /examples/batched-read-write

v1: https://www.redhat.com/archives/libguestfs/2019-June/msg00014.html I pushed a few bits which are uncontroversial. The main changes since v1 are: An extra patch removes the want_to_send / check for nbd_aio_is_ready in examples/threaded-reads-and-writes.c. This logic was wrong since commit 6af72b87 as was pointed out by Eric in his review. Comments and structure of

While working on a new test of what happens when the server goes away while commands are in flight, I managed to hit a race where I hit death from SIGPIPE instead of a clean transition to the DEAD state. I also found myself wanting to use nbd_poll from the test, but with a way to distinguish between the state machine progressing vs. hanging. Eric Blake (2): socket: Avoid SIGPIPE where possible

Rich recently patched things to generate one man page per function rather than libnbd-api.3 (nice), but in doing so got stumped by a problem with a fresh git clone (automake fails for any 'include' directive that does not already exist). I've figured out how to hack around it, but the hack requires GNU make. We already use GNU make constructs elsewhere (such as $(wildcard)), but

Hi I have upgraded from samba 3.6.19 to samba 4.0.13 on Debian Wheezy 64-bit with Samba 4.0.13 from wheezy-backports. I use winbind to authenticate against a two-server AD domain on Server 2012 functional level and forced LDAPS. After upgrading from 3.6.19 to 4.0.13 everything still works for me as usual. That is samba shares authentication, all things relying on the keytab, SSO logins with SSH

Once the client has requested NBD_CMD_DISC, the protocol states that it must not send any further information to the server (further writes may still be needed for a clean TLS shutdown, but that's a different matter requiring more states). Our state machine can prevent some of this if we have moved to CLOSED, but that's not foolproof because we can queue commands that can't be written

Hi! Occasionally of late, I've seen a few cases where libvirtd cpu usage shoots up to 100% and stays there indefinitely. This seems to happen when a QEMU VM is starting up, although on one occasion I *think* I saw it happen after a QEMU VM was p2p-migrated. Doing strace -f -p <libvirtd pid> reveals a flood of poll() functions calls like these: [pid 1690] poll([{fd=3,

I have identical two hypervisors same operating system: Ubuntu 22.04.2 LTS Recently both virsh stopped talking to the libvirtd. Both stopped within a few days of each other. Currently if I run: virsh uri virsh version virsh list # virsh list ..nothing just hangs When I ran strace on these broken machines it get stuck at same spot: strace virsh list ...

Automake insists that any file present in a Makefile.am 'include' must be present, but it has no idea about the GNU make extension 'sinclude'. Use this to our advantage: as long as Makefile.inc has nothing other than variable modifications (done in the previous patch), and our rules properly generate it when needed (thanks to generator_built), then running 'make' will

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