search for: handle_connection

If .prepare fails, we do not want to call .finalize (similar to how if .open fails, we do not want to call .close). However, the logic in backend_finalize was checking on the wrong condition ('was the connection opened' rather than 'was the connection prepared'), which led to an assertion failure. Simple reproducer: $ nbdkit -U - -f --filter cache --run 'qemu-io -r -c quit

Also add an inline accessor function (get_handle). This also removes the unused function connection_get_handle. --- server/internal.h | 24 ++++++++++++++++----- server/backend.c | 50 ++++++++++++++++++++++---------------------- server/connections.c | 11 +--------- 3 files changed, 45 insertions(+), 40 deletions(-) diff --git a/server/internal.h b/server/internal.h index

The retry filter was originally written to be the closest filter to the plugin, with no other filters in between; as such, the reopen command did not have to worry about recursion or about .prepare or .finalize. But it is not that much harder to properly track everything needed to allow other filters to be retried, as long as we are careful to never call .finalize unless .prepare succeeded, never

The immediate reason for this patch is to reduce the amount of debugging in virt-v2v with using the virt-v2v -v option (because this implies running nbdkit in verbose mode too). Most of the messages are datapath ones about pread/pwrite requests, and in fact as we've added more filters on top of nbdkit these messages have got more and more verbose. However they are not particularly

Hello everyone, I have a problem with a FastAGI connection, could you help me fix this problem please? Here is my log: [2015-12-15 16:17:09] WARNING[23936][C-00000015]: res_agi.c:1658 handle_connection: Connecting to '10.171.54.149:9110' failed for url 'agi://10.171.54.149:9110/DatabaseQuery.agi?vars=name%3Bfirst+name%3BStatut&db=Oracle+database&query=VIP&as=10.171.54.149': Connection refused [2015-12-15 16:17:09] WARNING[23936][C-00000015]: res_agi.c:1730 launch_netsc...

Now that a filter can open a backend as many times as it wants, there's no longer a technical reason we can't retry .open. However, adding retry logic here does mean we have to weaken an assert in the server backend code, since prepare can now be reached more than once. Test coverage will be added in a separate patch, so that it becomes easy to swap patch order and see that the test

Since commit 86fdb48c6a5362d66865493d9d2172166f99722e we have stored the connection object in thread-local storage. In this very large, but mostly mechanical change we stop passing the connection pointer around everywhere, and instead use the value stored in thread-local storage. This assumes a 1-1 mapping between the connection and the current thread which is true in *most* places.

v1 was here: https://www.redhat.com/archives/libguestfs/2020-February/msg00081.html v2 replaces struct connection *conn = GET_CONN; with GET_CONN; which sets conn implicitly and asserts that it is non-NULL. If we actually want to test if conn is non-NULL or behave differently, then you must use threadlocal_get_conn() instead, and some existing uses do that. Rich.

The third patch is a large but mechanical change which gets rid of passing around struct connection * entirely within the server, preferring instead to reference the connection through thread-local storage. I hope this is a gateway to simplifying other parts of the code. Rich.

On Fri, Jan 27, 2023 at 02:41:22PM -0600, Eric Blake wrote: > Now that a filter can open a backend as many times as it wants, > there's no longer a technical reason we can't retry .open. However, > adding retry logic here does mean we have to weaken an assert in the > server backend code, since prepare can now be reached more than once. > > Test coverage will be added

It's confusing to use the same terminology for a single backend as for the linked list of backends. In particular it's often not clear if we're calling the next backend or the whole chain of backends. --- server/internal.h | 14 ++++++++++-- server/connections.c | 20 ++++++++--------- server/locks.c | 2 +- server/main.c

I think this is my last round of patches for issues I identified with the retry filter. With this in place, it should be safe to interject another filter in between retry and the plugin. Eric Blake (5): retry: Don't call into closed plugin tests: Refactor test-retry-reopen-fail.sh tests: Enhance retry test to cover failed reopen server: Move prepare/finalize/close recursion to

In https://bugzilla.redhat.com/show_bug.cgi?id=1841820, it was pointed out that the retry filter not retrying .open means that an ssh connection (such as in a vmx+ssh v2v conversion) fails when the ssh connection itself cannot be retried. A year ago, this was an inherent limitation of our retry implementation; but in the meantime, my work to allow filters to open independent backends has made it

This fixes the long-standing crash on close when nbdkit exits. I did try first to fix threads so we're using a proper thread pool, but that's difficult to implement. So this does the minimal change needed to fix the crash instead. There are still two segfaults that happen during running the test suite. One is deliberately caused (tests/test-captive.sh). The other appears to be an

...orts/requests/10/0/frontend > Handling connection from dom=10, for export=0 > Frontend found at: /local/domain/10/device/vfs/0 (gref=1789, evtchn=5) > Our own dom_id=0 > ERROR Internal error: Could not open grant table interface (22 = Invalid argument) > fs-backend: fs-backend.c:239: handle_connection: Assertion `mount->gnth != -1'' failed. Mmm, are you perhaps running an old version of the dom0 kernel? Could you strace fs-backend to know which precise syscall is failing? M ^Mnet TX ring size 256 ^Mnet RX ring size 256 ^Mbackend at /local/domain/0/backend/vif/2/0 ^Mmac is 00:16:3e:6...

I'm about to add an 'exportname' filter, and in the process, I noticed a few shortcomings in our API. Having .default_export makes it easy to answer NBD_INFO_NAME in response to a client request during NBD_OPT_GO, but answering NBD_INFO_DESCRIPTION is awkward - there's no guarantee the export name was given with a description in .list_exports. Note, however, that while we map

I will be following up to this email with four separate threads each addressed to the appropriate single list, with proposed changes to: - the NBD protocol - qemu: both server and client - libnbd: client - nbdkit: server The feature in question adds a new optional NBD_INFO_ packet to the NBD_OPT_GO portion of handshake, adding up to 16 bits of information that the server can advertise to the

This is a revision of my .default_export work, plus new work on .export_descriptions and a new exportname filter. I think it is now ready to check in. Things I'd still like in 1.22: - the file plugin should implement .list_exports (patch already posted, but it needs rebasing on this series) - the ext2 filter should override .list_exports when in exportname mode - the nbd plugin should be

It's been several weeks since I posted v2 (I got distracted by improving libnbd to better test things, which in turn surfaced some major memory leak problems in nbdsh that are now fixed). Many of the patches are minor rebases from v2, with the biggest changes being fallout from: - patch 2: rename nbdkit_add_default_export to nbdkit_use_default_export - overall: this missed 1.22, so update