search for: nbd_unlock

With this, I am finally able to get the nbd plugin to do out-of-order responses to the client. Once this series goes in, we should be ready for Rich to cut a release. Eric Blake (4): nbd: Split reading into separate thread nbd: Protect writes with mutex nbd: Enable parallel handling tests: Test parallel nbd behavior plugins/nbd/nbd.c | 217

...*h, uint64_t cookie) +{ + struct transaction **ptr; + struct transaction *trans; + + nbd_lock (h); + ptr = &h->trans; + while ((trans = *ptr) != NULL) { + if (cookie == trans->u.cookie) + break; + ptr = &trans->next; + } + if (trans) + *ptr = trans->next; + nbd_unlock (h); + return trans; +} + /* Send a request, return 0 on success or -1 on write failure. */ static int nbd_request_raw (struct handle *h, uint32_t type, uint64_t offset, @@ -260,6 +280,8 @@ nbd_request_full (struct handle *h, uint32_t type, uint64_t offset, { int err; struct transaction...

...ans at most one outstanding transaction */ struct transaction trans; bool dead; @@ -179,6 +185,18 @@ write_full (int fd, const void *buf, size_t len) return 0; } +static void nbd_lock (struct handle *h) +{ + int r = pthread_mutex_lock (&h->lock); + assert (!r); +} + +static void nbd_unlock (struct handle *h) +{ + int r = pthread_mutex_unlock (&h->lock); + assert (!r); +} + /* Called during transmission phases when there is no hope of * resynchronizing with the server, and all further requests from the * client will fail. Returns -1 for convenience. */ @@ -187,6 +205,7...

...h, uint64_t cookie, bool remove) { struct transaction **ptr; struct transaction *trans; @@ -244,7 +248,7 @@ find_trans_by_cookie (struct handle *h, uint64_t cookie) break; ptr = &trans->next; } - if (trans) + if (trans && remove) *ptr = trans->next; nbd_unlock (h); return trans; @@ -303,6 +307,7 @@ nbd_request_full (struct handle *h, uint16_t flags, uint16_t type, } trans->buf = rep_buf; trans->count = rep_buf ? count : 0; + trans->offset = offset; nbd_lock (h); if (h->dead) { nbd_unlock (h); @@ -315,7 +320,7 @@ nbd_re...

I'm still working on the interleaving (and Rich reminded me on IRC that we still don't have THREAD_MODEL_PARALLEL working anywhere yet, anyways). Since nbdkit doesn't really have a parallel plugin yet, my testing on that front will have to use qemu-nbd as the original server, as well as qemu-io as the driver (qemu-io's aio_read and aio_write commands can be used to trigger

...andle) } /* Clean up any stranded in-flight requests */ - done = false; r = ESHUTDOWN; - while (!done) { + while (1) { struct transaction *trans; nbd_lock (h); trans = h->trans; - h->trans = trans->next; + h->trans = trans ? trans->next : NULL; nbd_unlock (h); + if (!trans) + break; if (write (trans->u.fds[1], &r, sizeof r) != sizeof r) { nbdkit_error ("failed to write pipe: %m"); abort (); -- 2.13.6

I'm hoping to implement .extents for the nbd plugin; this is a prerequisite. I'm not sure about patch 3 - if we like it, I'll squash it to 2, if we don't, I think we are okay just dropping it. I'm also wondering if we have to worry about malicious plugins that don't populate the entire .pread buffer in an effort to get nbdkit to expose portions of the heap; my patch 7 loses

Tested via: term1$ qemu-nbd -k $PWD/sock -t -f raw -x foo junk --trace=nbd_\* term2$ ./nbdkit -f -v -e bar nbd socket=$PWD/sock export=foo term3$ qemu-io -t none -f raw nbd://localhost:10809/bar --trace=nbd_\* and checking the traces to see that 'w 0 1' vs. 'w -f 0 1' was able to influence whether the FUA flag showed up at the server in term1. Still to go: figure out how to

A combination of the work that both Rich and I have been doing lately, where filters use only the new API with flags on every command that the client can send over the wire (we can then add support for more flags in nbdkit without having to add new callbacks, as NBD adds more flags upstream). Eric Blake (4): protocol: Split flags from cmd field in requests backend: Pass flags argument through