search for: error_data

...ings diff --git a/lib/errors.c b/lib/errors.c index def1d3c89..b0c678d77 100644 --- a/lib/errors.c +++ b/lib/errors.c @@ -51,26 +51,150 @@ #include "guestfs.h" #include "guestfs-internal.h" +/* How errors and error handlers works in the handle: + * + * The handle has a g->error_data field which is a thread-local + * storage (TLS) key. + * + * We use TLS because we want to support the common idioms of: + * if (guestfs_foo (g) == -1) + * printf ("%s\n", guestfs_last_error (g)); + * and: + * guestfs_push_error_handler (g, ...); + * guestfs_foo (g); + * guest...

...glong.m4 diff --git a/src/errors.c b/src/errors.c index d9959b2..d5d0308 100644 --- a/src/errors.c +++ b/src/errors.c @@ -29,10 +29,132 @@ #include "guestfs.h" #include "guestfs-internal.h" +/* How errors and error handlers works in the handle: + * + * The handle has a g->error_data field which is a thread-local + * storage (TLS) key. + * + * We use TLS because we want to support the common idioms of: + * if (guestfs_foo (g) == -1) + * printf ("%s\n", guestfs_last_error (g)); + * and: + * guestfs_push_error_handler (g, ...); + * guestfs_foo (g); + * guest...

Previous discussion here: https://www.redhat.com/archives/libguestfs/2015-June/thread.html#00048 v2: - Use a cleanup handler to release the lock. - Rebase to upstream. Note I have not fixed the problem(s) with error handling (patch 3).

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

This patch isn't ready to go upstream. In fact, I think we might do a quick 1.30 release soon, and save this patch, and also the extensive changes proposed for the test suite[1], to after 1.30. Currently it is not safe to use the same handle from multiple threads, unless you implement your own mutexes. See: http://libguestfs.org/guestfs.3.html#multiple-handles-and-multiple-threads These

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

...ainly because > POSIX doesn't give us useful destructor behaviour, so effectively we > end up creating our own destructor using a linked list. I'm not sure which behaviour you are referring to, but it should work just fine -- in the destructor function, cast the void* argument to the error_data struct, and free the linked list associated. The only problem is that the tls gnulib implementation on Windows (actually, on mingw) makes no use for the destructor function, but a) we don't have a working Windows port ATM (not even on other non-Linux Unices) b) using pthread or pth on mingw...

...uint64_t handle, uint16_t cmd, uint16_t flags, + uint32_t error) { ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&conn->write_lock); struct structured_reply reply; @@ -593,7 +596,7 @@ send_structured_reply_error (struct connection *conn, } /* Send the error. */ - error_data.error = htobe32 (nbd_errno (error)); + error_data.error = htobe32 (nbd_errno (error, flags & NBD_CMD_FLAG_DF)); error_data.len = htobe16 (0); r = conn->send (conn, &error_data, sizeof error_data); if (r == -1) { @@ -737,7 +740,8 @@ protocol_recv_request_send_reply (struct conne...

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

..., > + uint32_t error) > { > ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&conn->write_lock); > struct structured_reply reply; > @@ -593,7 +596,7 @@ send_structured_reply_error (struct connection *conn, > } > > /* Send the error. */ > - error_data.error = htobe32 (nbd_errno (error)); > + error_data.error = htobe32 (nbd_errno (error, flags & NBD_CMD_FLAG_DF)); > error_data.len = htobe16 (0); > r = conn->send (conn, &error_data, sizeof error_data); > if (r == -1) { > @@ -737,7 +740,8 @@ protocol_recv_request...

This time around, the numbers are indeed looking better than in v1; and I like the interface better. Eric Blake (2): server: Prefer send() over write() server: Group related transmission send()s server/internal.h | 7 +++- server/connections.c | 51 +++++++++++++++++++++++++--- server/crypto.c | 11 ++++--

...nd processed ok */ +} + +static int +send_structured_reply_error (struct connection *conn, + uint64_t handle, uint16_t cmd, uint32_t error) +{ + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&conn->write_lock); + struct structured_reply reply; + struct structured_reply_error error_data; + int r; + + reply.magic = htobe32 (NBD_STRUCTURED_REPLY_MAGIC); + reply.handle = handle; + reply.flags = htobe16 (NBD_REPLY_FLAG_DONE); + reply.type = htobe16 (NBD_REPLY_TYPE_ERROR); + reply.length = htobe32 (sizeof error_data + 0 /* no human readable error */); + + r = conn->send (conn...

...handle; - reply.error = htobe32 (nbd_errno (error, false)); + reply.error = htobe32 (nbd_errno (error, flags)); r = conn->send (conn, &reply, sizeof reply, f); if (r == -1) { @@ -640,7 +667,7 @@ send_structured_reply_error (struct connection *conn, } /* Send the error. */ - error_data.error = htobe32 (nbd_errno (error, flags & NBD_CMD_FLAG_DF)); + error_data.error = htobe32 (nbd_errno (error, flags)); error_data.len = htobe16 (0); r = conn->send (conn, &error_data, sizeof error_data, 0); if (r == -1) { @@ -790,5 +817,6 @@ protocol_recv_request_send_reply (st...

Required such that macOS doesn't crash in get_error_data (via call stack from guestfs_launch) >From 5b121bc8bb8f1fadf835b4af30cbb9c9e95af258 Mon Sep 17 00:00:00 2001 From: Daria Phoebe Brashear <dariaphoebe@auristor.com> Date: Tue, 4 Feb 2020 20:25:10 -0500 Subject: [PATCH] libhandle: initialize error_data_list_lock when a handle is allocated,...

...nd processed ok */ -} - -static int -send_structured_reply_error (struct connection *conn, - uint64_t handle, uint16_t cmd, uint32_t error) -{ - ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&conn->write_lock); - struct structured_reply reply; - struct structured_reply_error error_data; - int r; - - reply.magic = htobe32 (NBD_STRUCTURED_REPLY_MAGIC); - reply.handle = handle; - reply.flags = htobe16 (NBD_REPLY_FLAG_DONE); - reply.type = htobe16 (NBD_REPLY_TYPE_ERROR); - reply.length = htobe32 (0 /* no human readable error */ + sizeof error_data); - - r = conn->send (conn...

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.

...ly, sizeof reply, SEND_MORE); if (r == -1) { @@ -583,8 +584,8 @@ send_structured_reply_error (struct connection *conn, uint32_t error) { ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&conn->write_lock); - struct structured_reply reply; - struct structured_reply_error error_data; + struct nbd_structured_reply reply; + struct nbd_structured_reply_error error_data; int r; reply.magic = htobe32 (NBD_STRUCTURED_REPLY_MAGIC); @@ -616,7 +617,7 @@ int protocol_recv_request_send_reply (struct connection *conn) { int r; - struct request request; + struct nbd_reques...

...ck"); + /* While we're debugging locks in libguestfs I want this to fail + * noisily. + */ + abort (); + } + if (g->trace) { const char trace_msg[] = "close"; @@ -403,21 +435,6 @@ guestfs_close (guestfs_h *g) free (g->append); guestfs_int_free_error_data_list (g); gl_tls_key_destroy (g->error_data); - r = glthread_recursive_lock_destroy (&g->lock); - if (r != 0) { - /* If pthread_mutex_destroy returns 16 (EBUSY), this indicates - * that the lock is held somewhere. That means a programming - * error if the main program is...

..._error ("write uncork: %s: %m", name_of_nbd_cmd (cmd)); + return connection_set_status (conn, -1); + } + } + return 1; /* command processed ok */ } @@ -609,6 +648,11 @@ send_structured_reply_error (struct connection *conn, struct structured_reply_error error_data; int r; + if (conn->cork) { + r = conn->cork (conn, true); + assert (r == 0); /* For now, only uncorking can fail */ + } + reply.magic = htobe32 (NBD_STRUCTURED_REPLY_MAGIC); reply.handle = handle; reply.flags = htobe16 (NBD_REPLY_FLAG_DONE); @@ -631,6 +675,14 @@ send_str...

...end_structured_reply_error (uint64_t handle, uint16_t cmd, uint16_t flags, uint32_t error) { + struct connection *conn = GET_CONN; ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&conn->write_lock); struct nbd_structured_reply reply; struct nbd_structured_reply_error error_data; @@ -594,19 +594,19 @@ send_structured_reply_error (struct connection *conn, reply.type = htobe16 (NBD_REPLY_TYPE_ERROR); reply.length = htobe32 (0 /* no human readable error */ + sizeof error_data); - r = conn->send (conn, &reply, sizeof reply, SEND_MORE); + r = conn->send (&am...