summaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authorKevin Wolf2020-12-03 18:23:11 +0100
committerKevin Wolf2020-12-11 17:52:40 +0100
commit960d5fb3e8ee09bc5f1a5c84f66dce42a6cef920 (patch)
tree39067199e09a8bc788f23f6324a4a0a72d7e9a00 /include
parentblock: Fix locking in qmp_block_resize() (diff)
downloadqemu-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