From: Kevin Wolf <kwolf@redhat.com>
To: qemu-block@nongnu.org
Cc: kwolf@redhat.com, qemu-devel@nongnu.org
Subject: [PULL 08/12] block/nfs: Do not enter coroutine from CB
Date: Fri, 6 Mar 2026 19:37:01 +0100 [thread overview]
Message-ID: <20260306183705.410357-9-kwolf@redhat.com> (raw)
In-Reply-To: <20260306183705.410357-1-kwolf@redhat.com>
From: Hanna Czenczek <hreitz@redhat.com>
The reasoning I gave for why it would be safe to call aio_co_wake()
despite holding the mutex was wrong: It is true that the current request
will not re-acquire the mutex, but a subsequent request in the same
coroutine can. Because the mutex is a non-coroutine mutex, this will
result in a deadlock.
Therefore, we must either not enter the coroutine here (only scheduling
it), or release the mutex around aio_co_wake(). I opt for the former,
as it is the behavior prior to the offending commit, and so seems safe
to do.
Fixes: deb35c129b859b9bec70fd42f856a0b7c1dc6e61
("nfs: Run co BH CB in the coroutine’s AioContext")
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/2622#note_2965097035
Cc: qemu-stable@nongnu.org
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20260102153246.154207-1-hreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
---
block/nfs.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/block/nfs.c b/block/nfs.c
index 1d3a34a30c9..b78f4f86e85 100644
--- a/block/nfs.c
+++ b/block/nfs.c
@@ -249,14 +249,15 @@ nfs_co_generic_cb(int ret, struct nfs_context *nfs, void *data,
}
/*
- * Safe to call: nfs_service(), which called us, is only run from the FD
- * handlers, never from the request coroutine. The request coroutine in
- * turn will yield unconditionally.
- * No need to release the lock, even if we directly enter the coroutine, as
- * the lock is never re-taken after yielding. (Note: If we do enter the
- * coroutine, @task will probably be dangling once aio_co_wake() returns.)
+ * Using aio_co_wake() here could re-enter the coroutine directly, while we
+ * still hold the mutex. The current request will not attempt to re-take
+ * the mutex, so that is fine; but if the same coroutine then goes on to
+ * submit another request, that new request will try to re-take the mutex,
+ * resulting in a deadlock.
+ * To prevent that, only schedule the coroutine so it will be entered later,
+ * with the mutex released.
*/
- aio_co_wake(task->co);
+ aio_co_schedule(qemu_coroutine_get_aio_context(task->co), task->co);
}
static int coroutine_fn nfs_co_preadv(BlockDriverState *bs, int64_t offset,
@@ -716,8 +717,8 @@ nfs_get_allocated_file_size_cb(int ret, struct nfs_context *nfs, void *data,
if (task->ret < 0) {
error_report("NFS Error: %s", nfs_get_error(nfs));
}
- /* Safe to call, see nfs_co_generic_cb() */
- aio_co_wake(task->co);
+ /* Must not use aio_co_wake(), see nfs_co_generic_cb() */
+ aio_co_schedule(qemu_coroutine_get_aio_context(task->co), task->co);
}
static int64_t coroutine_fn nfs_co_get_allocated_file_size(BlockDriverState *bs)
--
2.53.0
next prev parent reply other threads:[~2026-03-06 18:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-06 18:36 [PULL 00/12] Block layer patches Kevin Wolf
2026-03-06 18:36 ` [PULL 01/12] block/vmdk: fix OOB read in vmdk_read_extent() Kevin Wolf
2026-03-06 18:36 ` [PULL 02/12] block: Wire up 'flat' mode also for 'query-block' Kevin Wolf
2026-03-06 18:36 ` [PULL 03/12] hmp_nbd_server_start: Don't ask for backing image data Kevin Wolf
2026-03-06 18:36 ` [PULL 04/12] block/curl: fix concurrent completion handling Kevin Wolf
2026-03-06 18:36 ` [PULL 05/12] mirror: Fix missed dirty bitmap writes during startup Kevin Wolf
2026-03-06 18:36 ` [PULL 06/12] block/throttle-groups: fix deadlock with iolimits and muliple iothreads Kevin Wolf
2026-03-06 18:37 ` [PULL 07/12] block: Never drop BLOCK_IO_ERROR with action=stop for rate limiting Kevin Wolf
2026-03-06 18:37 ` Kevin Wolf [this message]
2026-03-06 18:37 ` [PULL 09/12] qcow2: Add keep_data_file command-line option Kevin Wolf
2026-03-06 18:37 ` [PULL 10/12] qcow2: Simplify size round-up in co_create_opts Kevin Wolf
2026-03-06 18:37 ` [PULL 11/12] iotests/common.filter: Sort keep_data_file Kevin Wolf
2026-03-06 18:37 ` [PULL 12/12] iotests/244: Add test cases for keep_data_file Kevin Wolf
2026-03-07 11:22 ` [PULL 00/12] Block layer patches Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260306183705.410357-9-kwolf@redhat.com \
--to=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.