diff options
author | Kevin Wolf | 2020-12-03 18:23:11 +0100 |
---|---|---|
committer | Kevin Wolf | 2020-12-11 17:52:40 +0100 |
commit | 960d5fb3e8ee09bc5f1a5c84f66dce42a6cef920 (patch) | |
tree | 39067199e09a8bc788f23f6324a4a0a72d7e9a00 /include | |
parent | block: Fix locking in qmp_block_resize() (diff) | |
download | qemu-960d5fb3e8ee09bc5f1a5c84f66dce42a6cef920.tar.gz qemu-960d5fb3e8ee09bc5f1a5c84f66dce42a6cef920.tar.xz qemu-960d5fb3e8ee09bc5f1a5c84f66dce42a6cef920.zip |
block: Fix deadlock in bdrv_co_yield_to_drain()
If bdrv_co_yield_to_drain() is called for draining a block node that
runs in a different AioContext, it keeps that AioContext locked while it
yields and schedules a BH in the AioContext to do the actual drain.
As long as executing the BH is the very next thing that the event loop
of the node's AioContext does, this actually happens to work, but when
it tries to execute something else that wants to take the AioContext
lock, it will deadlock. (In the bug report, this other thing is a
virtio-scsi device running virtio_scsi_data_plane_handle_cmd().)
Instead, always drop the AioContext lock across the yield and reacquire
it only when the coroutine is reentered. The BH needs to unconditionally
take the lock for itself now.
This fixes the 'block_resize' QMP command on a block node that runs in
an iothread.
Cc: qemu-stable@nongnu.org
Fixes: eb94b81a94bce112e6b206df846c1551aaf6cab6
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1903511
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20201203172311.68232-4-kwolf@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions