search for: acquire_lock_for_current_scop

.../cache/cache.c index 6a9966e..b3fef42 100644 --- a/filters/cache/cache.c +++ b/filters/cache/cache.c @@ -209,9 +209,8 @@ cache_get_size (struct nbdkit_next_ops *next_ops, void *nxdata, nbdkit_debug ("cache: underlying file size: %" PRIi64, size); - pthread_mutex_lock (&lock); + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&lock); r = blk_set_size (size); - pthread_mutex_unlock (&lock); if (r == -1) return -1; @@ -266,9 +265,10 @@ cache_pread (struct nbdkit_next_ops *next_ops, void *nxdata, if (n > count) n = count; - pthread_mutex_lock (&lock); - r = blk_read (next_op...

...-plugin.h> +#include "cleanup.h" #include "sparse.h" /* If raw|base64|data parameter seen. */ @@ -339,9 +340,8 @@ data_can_multi_conn (void *handle) static int data_pread (void *handle, void *buf, uint32_t count, uint64_t offset) { - pthread_mutex_lock (&lock); + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&lock); sparse_array_read (sa, buf, count, offset); - pthread_mutex_unlock (&lock); return 0; } @@ -349,21 +349,16 @@ data_pread (void *handle, void *buf, uint32_t count, uint64_t offset) static int data_pwrite (void *handle, const void *buf, uint32_t count, uint64_t offset) {...

...kit_error ("malloc: %m"); + return -1; + } } + blknum = offset / blksize; /* block number */ + blkoffs = offset % blksize; /* offset within the block */ + + /* Unaligned head */ + if (blkoffs) { + uint64_t n = MIN (blksize - blkoffs, count); + + assert (block); + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&lock); + r = blk_read (next_ops, nxdata, blknum, block, err); + if (r == -1) + return -1; + + memcpy (buf, &block[blkoffs], n); + + buf += n; + count -= n; + offset += n; + blknum++; + } + + /* Aligned body */ /* XXX This breaks up large read requests into...

I do have a question about whether patch 2 is right, or whether I've exposed a bigger problem in the truncate (and possibly other) filter, but the rest seem fairly straightforward. Eric Blake (4): server: Check for pthread lock failures truncate: Factor out reading real_size under mutex plugins: Check for mutex failures filters: Check for mutex failures filters/cache/cache.c

...h" + #define THREAD_MODEL NBDKIT_THREAD_MODEL_PARALLEL static uint64_t connections; @@ -114,12 +116,8 @@ struct handle { static uint64_t get_id (struct handle *h) { - uint64_t r; - - pthread_mutex_lock (&lock); - r = ++h->id; - pthread_mutex_unlock (&lock); - return r; + ACQUIRE_LOCK_FOR_CURRENT_SCOPE(&lock); + return ++h->id; } /* Output a timestamp and the log message. */ diff --git a/filters/readahead/readahead.c b/filters/readahead/readahead.c index 5e14347..f46b6b0 100644 --- a/filters/readahead/readahead.c +++ b/filters/readahead/readahead.c @@ -42,6 +42,7 @@ #include <nbd...

Previously posted in 2015: v1: https://www.redhat.com/archives/libguestfs/2015-June/msg00048.html v2: https://www.redhat.com/archives/libguestfs/2015-June/msg00118.html I have rebased and tidied up the patches, fixing a few spelling mistakes, but they are broadly the same as before. I also ran all the tests, which pass. As with the previous versions, this makes a change to the API, where you

Based on Rich's review of my v1 that touched only cache.c, I have now tried to bring all three filters with alignment rounding in line with one another. There is definitely room for future improvements once we teach nbdkit to let filters and plugins advertise block sizes, but I'm hoping to get NBD_CMD_CACHE implemented first. Eric Blake (2): blocksize: Process requests in linear order

...common/utils, but it looks like the former is for things that are inlineable via .h only, while the latter is when you need to link in a convenience library, so this landed in the latter. Eric Blake (4): cleanup: Move cleanup.c to common filters: Utilize CLEANUP_EXTENTS_FREE filters: Utilize ACQUIRE_LOCK_FOR_CURRENT_SCOPE plugins: Utilize ACQUIRE_LOCK_FOR_CURRENT_SCOPE common/utils/cleanup.h | 48 ++++++++++++++++++++++++++++++ server/internal.h | 12 +------- {server => common/utils}/cleanup.c | 5 ++-- filters/log/log.c | 10 +++---- filters/offset/offset.c...

Hi Richard! Maybe the function guestfs_mount_local_run shouldn't ACQUIRE_LOCK_FOR_CURRENT_SCOPE as it doesn't talk with the daemon and sits in the loop? What do you think? If I remove it from guestfs_mount_local_run (in lib/action-1.c, don't know how to properly remove it from ml generator), fuse_loop_mt works, but I still don't understand how it worked with fuse_loop (single thr...

...int32_t flags, int *err) { + struct timeval start, end; + int64_t usecs; int r; + gettimeofday (&start, NULL); r = next_ops->pread (nxdata, buf, count, offset, flags, err); if (r == 0) { + gettimeofday (&end, NULL); + usecs = tvdiff_usec(&start, &end); + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&lock); pread_ops++; pread_bytes += count; + pread_usecs += usecs; } return r; } @@ -204,13 +211,20 @@ stats_pwrite (struct nbdkit_next_ops *next_ops, void *nxdata, const void *buf, uint32_t count, uint64_t offset, uint32_t flags, int *err) {...

I believe this roughly implements Nir's proposal here: https://www.redhat.com/archives/libguestfs/2020-August/msg00028.html Unfortunately it doesn't work for me. It actually slows things down quite a lot, for reasons I don't understand. Note the adjustment of the pool-max parameter and how it affects the total time. The results are quite reproducible. $ ./nbdkit -r -U - vddk

We had a query yesterday about the VDDK plugin and making it actually obey the weird "Multithreading Considerations" rules in the VDDK documentation (https://vdc-download.vmware.com/vmwb-repository/dcr-public/8f96698a-0e7b-4d67-bb6c-d18a1d101540/ef536a47-27cd-481a-90ef-76b38e75353c/vsphere-vddk-671-programming-guide.pdf) This patch is my attempt to implement this. The idea is that the

...bove. */ > +static pthread_mutex_t open_close_lock = PTHREAD_MUTEX_INITIALIZER; > > /* The per-connection handle. */ > struct vddk_handle { > @@ -524,6 +531,7 @@ free_connect_params (VixDiskLibConnectParams *params) > static void * > vddk_open (int readonly) > { > + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&open_close_lock); > struct vddk_handle *h; > VixError err; > uint32_t flags; > @@ -616,6 +624,7 @@ vddk_open (int readonly) > static void > vddk_close (void *handle) > { > + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&open_close_lock); > struct vddk_handle...

...mp_plugin (void) #endif } +static int file_list_exports (int readonly, int default_only, + struct nbdkit_exports *exports) +{ + struct dirent *entry; + struct stat sb; + int fd; + + if (!directory) + return nbdkit_add_export (exports, "", NULL); + + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&lock); + rewinddir (dir); + fd = dirfd (dir); + if (fd == -1) { + nbdkit_error ("dirfd: %m"); + return -1; + } + errno = 0; + while ((entry = readdir (dir)) != NULL) { + /* TODO: Optimize with d_type and/or statx when present? */ + if (fstatat (fd, entry->d_nam...

...+ gl_lock_unlock (g->error_data_list_lock); + + /* Set the TLS to point to the struct. This is safe because we + * should have acquired the handle lock. + */ + gl_tls_set (g->error_data, ret); + } + + return ret; +} + const char * guestfs_last_error (guestfs_h *g) { ACQUIRE_LOCK_FOR_CURRENT_SCOPE (g); - return g->last_error; + return get_error_data (g)->last_error; } int guestfs_last_errno (guestfs_h *g) { ACQUIRE_LOCK_FOR_CURRENT_SCOPE (g); - return g->last_errnum; + return get_error_data (g)->last_errnum; } static void set_last_error (guestfs_h *g, int errnu...

Previously posted in 2015: v1: https://www.redhat.com/archives/libguestfs/2015-June/msg00048.html v2: https://www.redhat.com/archives/libguestfs/2015-June/msg00118.html This series was posted about 4 weeks ago: v3: https://www.redhat.com/archives/libguestfs/2017-June/msg00287.html There is no change in this series except I rebased it against current upstream head and retested. Last time there

...e to execute several simultaneous reads, for example? If yes, how many threads it uses? Or every request starts its own thread? Thanks much, Maxim. On Oct 18, 2017 2:17 AM, "Maxim Kozover" <maximkoz@gmail.com> wrote: > Hi Richard! > Finally it seems it works after removing ACQUIRE_LOCK_FOR_CURRENT_SCOPE > in guestfs_mount_local_run and throwing away all directory cache code. > Although I didn't try to mix fuse libguestfs client with other clients, I > think guestfs_mount_local_run shouldn't take that specific lock as the > function won't exit until umount and will sit in t...

...ksize); + if (block == NULL) { + *err = errno; + nbdkit_error ("malloc: %m"); + return -1; + } } /* XXX This breaks up large read requests into smaller ones, which @@ -258,12 +261,14 @@ cache_pread (struct nbdkit_next_ops *next_ops, void *nxdata, { ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&lock); - r = blk_read (next_ops, nxdata, blknum, block, err); + r = blk_read (next_ops, nxdata, blknum, + blkoffs || n < blksize ? block : buf, err); } if (r == -1) return -1; - memcpy (buf, &block[blkoffs], n); + if (blkoffs || n &...

...data_size; nbdkit_debug ("final size: %" PRIi64, size); + sparse_array_set_size (sa, size); return 0; } @@ -378,6 +379,22 @@ data_can_fast_zero (void *handle) return 1; } +/* Does current client start with a sparse image. */ +static int +data_init_sparse (void *handle) +{ + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&lock); + return sparse_array_is_sparse (sa); +} + +/* Does current client start with all zeroes. */ +static int +data_init_zero (void *handle) +{ + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&lock); + return sparse_array_is_zero (sa); +} + /* Read data. */ static int data_pread (void *handle,...

...et a free handle. + */ + pthread_mutex_t vddk_handles_lock; + pthread_cond_t vddk_handles_cond; + vddk_handles vddk_handles; }; static inline VixDiskLibConnectParams * @@ -531,17 +556,28 @@ free_connect_params (VixDiskLibConnectParams *params) static void * vddk_open (int readonly) { - ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&open_close_lock); - struct vddk_handle *h; + struct handle *h; VixError err; - uint32_t flags; - h = malloc (sizeof *h); + h = calloc (1, sizeof *h); if (h == NULL) { - nbdkit_error ("malloc: %m"); + nbdkit_error ("calloc: %m"); return NULL; }...