"Denis V. Lunev" <address@hidden> wrote:
aio_context should be locked in the similar way as was done in QMP
snapshot creation in the other case there are a lot of possible
troubles if native AIO mode is enabled for disk.
- the command can hang (HMP thread) with missed wakeup (the operation is
actually complete)
io_submit
ioq_submit
laio_submit
raw_aio_submit
raw_aio_readv
bdrv_co_io_em
bdrv_co_readv_em
bdrv_aligned_preadv
bdrv_co_do_preadv
bdrv_co_do_readv
bdrv_co_readv
qcow2_co_readv
bdrv_aligned_preadv
bdrv_co_do_pwritev
bdrv_rw_co_entry
- QEMU can assert in coroutine re-enter
__GI_abort
qemu_coroutine_enter
bdrv_co_io_em_complete
qemu_laio_process_completion
qemu_laio_completion_bh
aio_bh_poll
aio_dispatch
aio_poll
iothread_run
qemu_fopen_bdrv and bdrv_fclose are used in real snapshot operations only
along with block drivers. This change should influence only HMP snapshot
operations.
AioContext lock is reqursive. Thus nested locking should not be a problem.
Signed-off-by: Denis V. Lunev <address@hidden>
CC: Stefan Hajnoczi <address@hidden>
CC: Paolo Bonzini <address@hidden>
CC: Juan Quintela <address@hidden>
CC: Amit Shah <address@hidden>
Reviewed-by: Juan Quintela <address@hidden>
Should this one go through the block layer? I guess that the block
layer, but otherwise, I will get it.