search for: nbd_lock

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

...d_t reader; + + pthread_mutex_t lock; /* Covers access to all fields below */ /* Our choice of THREAD_MODEL means 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 t...

...227,6 +227,26 @@ nbd_mark_dead (struct handle *h) return -1; } +/* Find and remove the transaction corresponding to cookie from the list. */ +static struct transaction * +find_trans_by_cookie (struct handle *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 fai...

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

.../nbd/nbd.c index a4a9639..df49a1d 100644 --- a/plugins/nbd/nbd.c +++ b/plugins/nbd/nbd.c @@ -384,15 +384,16 @@ nbd_reader (void *handle) } /* 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");...

...(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_request_full (struct handle *h, uint16_t flags, uint16_t type, nbd_unlock (h); if (nbd_request_raw (h, flags, type, offset, count, cookie, req_buf) == 0) return fd; - trans = find_trans_by_cookie (h, cookie); + tran...

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