search for: cleanup_unlock

...s? common/utils/cleanup.h | 5 ++++- common/utils/cleanup.c | 3 ++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/common/utils/cleanup.h b/common/utils/cleanup.h index e6e6140..0ab9e65 100644 --- a/common/utils/cleanup.h +++ b/common/utils/cleanup.h @@ -43,6 +43,9 @@ extern void cleanup_unlock (pthread_mutex_t **ptr); #define CLEANUP_UNLOCK __attribute__((cleanup (cleanup_unlock))) #define ACQUIRE_LOCK_FOR_CURRENT_SCOPE(mutex) \ CLEANUP_UNLOCK pthread_mutex_t *_lock = mutex; \ - pthread_mutex_lock (_lock) + do { \ + int _r = pthread_mutex_lock (_lock); \ + assert (!_r); \ +...

..._H +#define NBDKIT_CLEANUP_H + +#include <pthread.h> + +extern void cleanup_free (void *ptr); +#define CLEANUP_FREE __attribute__((cleanup (cleanup_free))) +extern void cleanup_extents_free (void *ptr); +#define CLEANUP_EXTENTS_FREE __attribute__((cleanup (cleanup_extents_free))) +extern void cleanup_unlock (pthread_mutex_t **ptr); +#define CLEANUP_UNLOCK __attribute__((cleanup (cleanup_unlock))) +#define ACQUIRE_LOCK_FOR_CURRENT_SCOPE(mutex) \ + CLEANUP_UNLOCK pthread_mutex_t *_lock = mutex; \ + pthread_mutex_lock (_lock) + +#endif /* NBDKIT_CLEANUP_H */ diff --git a/server/internal.h b/server/inte...

...6 +139,8 @@ extern void change_user (void); /* cleanup.c */ extern void cleanup_free (void *ptr); #define CLEANUP_FREE __attribute__((cleanup (cleanup_free))) +extern void cleanup_extents_free (void *ptr); +#define CLEANUP_EXTENTS_FREE __attribute__((cleanup (cleanup_extents_free))) extern void cleanup_unlock (pthread_mutex_t **ptr); #define CLEANUP_UNLOCK __attribute__((cleanup (cleanup_unlock))) #define ACQUIRE_LOCK_FOR_CURRENT_SCOPE(mutex) \ diff --git a/server/cleanup.c b/server/cleanup.c index c29ecec..1eec613 100644 --- a/server/cleanup.c +++ b/server/cleanup.c @@ -1,5 +1,5 @@ /* nbdkit - * Cop...

...b/common/utils/cleanup.h @@ -40,6 +40,9 @@ extern void cleanup_free (void *ptr); #define CLEANUP_FREE __attribute__((cleanup (cleanup_free))) +extern void cleanup_free_string_list (char ***ptr); +#define CLEANUP_FREE_STRING_LIST __attribute__((cleanup (cleanup_free_string_list))) + extern void cleanup_unlock (pthread_mutex_t **ptr); #define CLEANUP_UNLOCK __attribute__((cleanup (cleanup_unlock))) diff --git a/common/utils/cleanup.c b/common/utils/cleanup.c index fb77805b..a9759ec4 100644 --- a/common/utils/cleanup.c +++ b/common/utils/cleanup.c @@ -44,6 +44,19 @@ cleanup_free (void *ptr) free (*...

There's more that can be done (in particular, use of CLEANUP_FREE), but this is enough to at least see if I'm on the right track. I couldn't figure out an obvious difference between common/include and 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

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

This was a rather longer trip around the houses than I anticipated! The basic purpose of the patch series is to set $nbdkit_stdio_safe to "0" or "1" in sh and eval plugin scripts. To do that, I ended up adding a nicer way to manipulate environ lists, and to do that, I ended up adding a whole generic vector implementation which is applicable in a lot of different places.

Not sure what version we're up to, but this reimplements extents using the new simpler structure described in this thread: https://www.redhat.com/archives/libguestfs/2019-March/msg00077.html I also fixed most of the things that Eric pointed out in the previous review, although I need to go back over his replies and check I've got everything. This needs a bit more testing. However the

I'm not sure exactly which version we're up to, but let's say it's version 4. I'm a lot happier with this version: - all filters have been reviewed and changed where I think that's necessary - can_extents is properly defined and implemented now - NBD protocol is followed - I believe it addresses all previous review points where possible The "only" thing

I want to post this but mainly for discussion and early review. It's not safe for these patches to all go upstream yet (because not all filters have been checked/adjusted), but if any patches were to go upstream then probably 1 & 2 only are safe. File, VDDK, memory and data plugins all work, although I have only done minimal testing on them. The current tests, such as they are, all

...+ const char **argv) + __attribute__((__nonnull__ (1, 3))); extern char tmpdir[]; extern char *script; diff --git a/server/internal.h b/server/internal.h index 68c9636..a89b41c 100644 --- a/server/internal.h +++ b/server/internal.h @@ -125,24 +125,44 @@ extern void cleanup_unlock (pthread_mutex_t **ptr); /* connections.c */ struct connection; -typedef int (*connection_recv_function) (struct connection *, void *buf, size_t len); -typedef int (*connection_send_function) (struct connection *, const void *buf, size_t len); -typedef void (*connection_close_function) (struct...

v1 was here: https://www.redhat.com/archives/libguestfs/2019-January/msg00008.html In v2 I have provided two patches: The first patch extends attribute((nonnull)) to most internal functions, but not to the external API. The second patch uses a macro so that attribute((format)) is only used in the public API on GCC or Clang. At least in theory these headers could be used by a C compiler which

This has already been pushed upstream. I am simply posting these here so we have a reference in the mailing list in case we find bugs later (as I'm sure we will - it's a complex patch series). Great thanks to Eric Blake for tireless review on this one. It also seems to have identified a few minor bugs in qemu along the way. Rich.

These are a couple of patches in preparation for the Block Status implementation. While the patches (especially the second one) are very large they are really just elementary code motion. Rich.