Re: [Qemu-devel] [PATCH 4/5] migration: add missed aio_context_acquire into hmp_savevm/hmp_delvm

[Denis V. Lunev]

On 10/28/2015 01:11 PM, Juan Quintela wrote:
> "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
> >
> > 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>
> > ---
> >   block/snapshot.c   | 5 +++++
> >   migration/savevm.c | 7 +++++++
> >   2 files changed, 12 insertions(+)
>
>
> Reviewed-by: Juan Quintela <address@hidden>
>
> But once there, I can't understand why migration have to know about
> aio_contexts at all.
>
> I *think* that it would be a good idea to "hide" the
> adi_context_acquire(aio_context) inside qemu_fopen_bdrv() (yes, it is
> still in migration/*, but you get the idea).  But don't propose it,
> because we don't have qemu_fclose_bdrv().  Yes we could add an
> aio_context inside QemuFile, and release it on qemu_fclose(), but I
> guess this needs more thought yet.
>
> BTW, once that I got your attention, why is this needed on hmp_savevm()
> but it is not needed on load_vmstate()?  We are also using
> qemu_fopen_bdrv()?  Because we are only reading from there?  Just curios
> the reason or if we are missing something there.
>
> Thanks, Juan.

I think that the race is still there (I have checked this several times 
but less
amount of times then create/delete snapshot) but the windows is seriously
reduced due to bdrv_drain_all at the beginning.

In general your are right. But in this case we are almost doomed. Any single
read/write operation could executed in iothread only. May be I have missed
something in this puzzle.

OK. What about bdrv_fclose callback and similar (new) callback for open
which should be called through qemu_fopen_bdrv for block driver only?

Den