search for: recv_request_send_reply

I want to make my nbd forwarding plugin fully parallel - but to do that, I first need to make nbdkit itself fully parallel ;) With this series, I was finally able to demonstrate out-of-order responses when using qemu-io (which is great at sending back-to-back requests prior to waiting for responses) coupled with the nbd file plugin (which has a great feature of rdelay and wdelay, to make it

...conn->request_lock); + pthread_mutex_destroy (&conn->read_lock); + pthread_mutex_destroy (&conn->write_lock); /* Don't call the plugin again if quit has been set because the main * thread will be in the process of unloading it. The plugin.unload @@ -888,19 +894,23 @@ recv_request_send_reply (struct connection *conn) CLEANUP_FREE char *buf = NULL; /* Read the request packet. */ + pthread_mutex_lock (&conn->read_lock); r = conn->recv (conn, &request, sizeof request); if (r == -1) { nbdkit_error ("read request: %m"); + pthread_mutex_unlock (&...

...pthread_mutex_destroy (&conn->read_lock); > + pthread_mutex_destroy (&conn->write_lock); > > /* Don't call the plugin again if quit has been set because the main > * thread will be in the process of unloading it. The plugin.unload > @@ -888,19 +894,23 @@ recv_request_send_reply (struct connection *conn) > CLEANUP_FREE char *buf = NULL; > > /* Read the request packet. */ > + pthread_mutex_lock (&conn->read_lock); > r = conn->recv (conn, &request, sizeof request); > if (r == -1) { > nbdkit_error ("read request: %m&q...

...cated ==20307== ==20307== 96 bytes in 3 blocks are definitely lost in loss record 4 of 10 ==20307== at 0x4C2FA1E: calloc (vg_replace_malloc.c:711) ==20307== by 0x77EBBAF: ??? ==20307== by 0x77EBD17: ??? ==20307== by 0x40595C: handle_request (connections.c:894) ==20307== by 0x40595C: recv_request_send_reply (connections.c:1061) ==20307== by 0x405AE7: connection_worker (connections.c:200) ==20307== by 0x55DC55A: start_thread (in /usr/lib64/libpthread-2.26.9000.so) ==20307== by 0x58E85AE: clone (in /usr/lib64/libc-2.26.9000.so) ==20307== ==20307== 320 bytes in 10 blocks are definitely lost in...

I've posted some of these patches or ideas before; but now I'm confident enough with the series that it should be ready to push; at any rate, I can now run test-socket-activation in a tight loop without triggering any crashes or hangs. With this in place, I'm going back to work on making the nbd forwarder wort with the parallel thread model. Eric Blake (8): sockets: Use

...over the network. While our plugin waits for the read or write data we don't block in a thread we handle other requests that are ready). The current nbdkit server design requires a thread per request in progress because it is built around a synchronous callback to the plugin layer and the main recv_request_send_reply loop holds the only copy of the request handle that is needed to make the reply. A more flexible design would be the recv_request_send_reply loop is instead split into a recv_request loop and a send_reply func. The recv_request loop forwards the request handle to the handle_request call. The exist...

When facing a malicious client that is sending bogus NBD_CMD_READ, we should make sure that we never end up in a situation where we could try to treat the tail from a command that we diagnosed as bad as being further commands. Eric Blake (2): connections: Report mid-message EOF as fatal connections: Hang up early on insanely large WRITE requests src/connections.c | 35

With some crufty sed scripts we can generate functions that map from NBD protocol flags (eg. NBD_CMD_READ) to strings ("NBD_CMD_READ"). This works on GNU sed and with FreeBSD, also with GNU sed's --posix option, so I guess the sed code is POSIX-compatible. Rich.

...;invalid request: trim operation not supported"); *error = EINVAL; - return 0; + return false; } - return 1; /* Commands validates. */ + return true; /* Command validates. */ } /* Grab the appropriate error value. @@ -970,10 +968,7 @@ recv_request_send_reply (struct connection *conn) } /* Validate the request. */ - r = validate_request (conn, cmd, flags, offset, count, &error); - if (r == -1) - return -1; - if (r == 0) { /* request not valid */ + if (!validate_request (conn, cmd, flags, offset, count, &error)) {...

Commit 9e6d990f exposed a pre-existing deadlock between the nbd plugin as client and parallel nbdkit as server. Prior to that commit, the deadlock was "resolved" because we unloaded the .so in parallel to a .close callback that never completed (yes, it's nasty that it usually? let the testsuite pass), but now we correctly refuse to unload a plugin that has not returned from .close,

...rror_data, sizeof error_data); + if (r == -1) { + nbdkit_error ("write data: %s: %m", name_of_nbd_cmd (cmd)); + return set_status (conn, -1); + } + /* No human readable error message at the moment. */ + + return 1; /* command processed ok */ +} + static int recv_request_send_reply (struct connection *conn) { int r; struct request request; - struct reply reply; uint16_t cmd, flags; uint32_t magic, count, error = 0; uint64_t offset; @@ -1317,40 +1449,33 @@ recv_request_send_reply (struct connection *conn) /* Send the reply packet. */ send_reply: - { -...

...A) { + nbdkit_error ("invalid request: unknown flag (0x%x)", flags); + *error = EINVAL; + return 0; + } + /* Refuse over-large read and write requests. */ if ((cmd == NBD_CMD_WRITE || cmd == NBD_CMD_READ) && count > MAX_REQUEST_SIZE) { @@ -741,7 +748,7 @@ recv_request_send_reply (struct connection *conn) } cmd = be32toh (request.type); - flags = cmd; + flags = cmd & ~NBD_CMD_MASK_COMMAND; cmd &= NBD_CMD_MASK_COMMAND; offset = be64toh (request.offset); -- 2.9.3

...ock go away. Signed-off-by: Eric Blake <eblake@redhat.com> --- src/connections.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/connections.c b/src/connections.c index 46f2cd4..6c1f8cd 100644 --- a/src/connections.c +++ b/src/connections.c @@ -1056,8 +1056,9 @@ recv_request_send_reply (struct connection *conn) /* Read the request packet. */ { ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&conn->read_lock); - if (get_status (conn) < 0) - return -1; + r = get_status (conn); + if (r <= 0) + return r; r = conn->recv (conn, &request, sizeof re...

Fixes for various issues found while implementing my nbd forwarder plugin. I'm okay if you choose to take some but not others; the most important one is patch 3 which fixes a protocol violation that makes it impossible for a client to try and recover from EIO failures over a partially-flaky source block device. Eric Blake (3): maint: Add emacs hint file maint: Add NBDKIT_GDB support to

...e32 (sizeof offset_data + count); This line is correct, but I had to remind myself of C precedence rules on this one; writing 'count + sizeof offset_data' instead has the same effect without worrying whether sizeof binds with higher or lower precedence than +. > @@ -1317,40 +1449,33 @@ recv_request_send_reply (struct connection *conn) > > /* Send the reply packet. */ > send_reply: > - { > - ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&conn->write_lock); > - if (get_status (conn) < 0) > - return -1; > - reply.magic = htobe32 (NBD_REPLY_MAGIC); > - reply.h...

----- Forwarded message ----- Date: Sat, 18 Feb 2017 22:21:19 -0500 Subject: nbdkit async Hello, Hope this is the right person to contact regarding nbdkit design. I have a high latency massively parallel device that I am currently implementing as an nbdkit plugin in c++ and have run into some design limitations due to the synchronous callback interface nbdkit requires. Nbdkit is currently

...ion *conn) { int r; - plugin_lock_request (conn); + lock_request (conn); if (!newstyle) r = _negotiate_handshake_oldstyle (conn); else r = _negotiate_handshake_newstyle (conn); - plugin_unlock_request (conn); + unlock_request (conn); return r; } @@ -1057,9 +1057,9 @@ recv_request_send_reply (struct connection *conn) error = ESHUTDOWN; } else { - plugin_lock_request (conn); + lock_request (conn); error = handle_request (conn, cmd, flags, offset, count, buf); - plugin_unlock_request (conn); + unlock_request (conn); } /* Send the reply packet. */ diff...

...ion *conn) { int r; - plugin_lock_request (conn); + lock_request (conn); if (!newstyle) r = _negotiate_handshake_oldstyle (conn); else r = _negotiate_handshake_newstyle (conn); - plugin_unlock_request (conn); + unlock_request (conn); return r; } @@ -1057,9 +1057,9 @@ recv_request_send_reply (struct connection *conn) error = ESHUTDOWN; } else { - plugin_lock_request (conn); + lock_request (conn); error = handle_request (conn, cmd, flags, offset, count, buf); - plugin_unlock_request (conn); + unlock_request (conn); } /* Send the reply packet. */ diff...

...dshake (conn) == -1) goto done; - if (nworkers == 1) { + if (!nworkers) { /* No need for a separate thread. */ debug ("handshake complete, processing requests serially"); - nworkers = conn->nworkers = 0; while (!quit && get_status (conn) > 0) recv_request_send_reply (conn); } diff --git a/src/internal.h b/src/internal.h index 1fc5d69..b79c12c 100644 --- a/src/internal.h +++ b/src/internal.h @@ -103,6 +103,7 @@ extern const char *tls_certificates_dir; extern int tls_verify_peer; extern char *unixsocket; extern int verbose; +extern int threads; extern vo...

On Wed, Jan 31, 2018 at 09:26:37PM -0600, Eric Blake wrote: > Previously, we let a plugin set an error in either thread-local > storage (nbdkit_set_error()) or errno, then connections.c would > decode which error to use. But with filters in the mix, it is > very difficult for a filter to know what error was set by the > plugin (particularly since nbdkit_set_error() has no public