diff options
| author | Kevin Wolf <kwolf@redhat.com> | 2023-05-17 17:28:32 +0200 |
|---|---|---|
| committer | Kevin Wolf <kwolf@redhat.com> | 2023-05-19 19:16:53 +0200 |
| commit | 80fc5d260002432628710f8b0c7cfc7d9b97bb9d (patch) | |
| tree | c0a397e67f8711a120340993ab5273473c0c4c2d /nbd | |
| parent | 844a12a63e12b1235a8fc17f9b278929dc6eb00e (diff) | |
| download | qemu-80fc5d260002432628710f8b0c7cfc7d9b97bb9d.zip qemu-80fc5d260002432628710f8b0c7cfc7d9b97bb9d.tar.gz qemu-80fc5d260002432628710f8b0c7cfc7d9b97bb9d.tar.bz2 | |
graph-lock: Disable locking for now
In QEMU 8.0, we've been seeing deadlocks in bdrv_graph_wrlock(). They
come from callers that hold an AioContext lock, which is not allowed
during polling. In theory, we could temporarily release the lock, but
callers are inconsistent about whether they hold a lock, and if they do,
some are also confused about which one they hold. While all of this is
fixable, it's not trivial, and the best course of action for 8.0.1 is
probably just disabling the graph locking code temporarily.
We don't currently rely on graph locking yet. It is supposed to replace
the AioContext lock eventually to enable multiqueue support, but as long
as we still have the AioContext lock, it is sufficient without the graph
lock. Once the AioContext lock goes away, the deadlock doesn't exist any
more either and this commit can be reverted. (Of course, it can also be
reverted while the AioContext lock still exists if the callers have been
fixed.)
Cc: qemu-stable@nongnu.org
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20230517152834.277483-2-kwolf@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'nbd')
0 files changed, 0 insertions, 0 deletions