On Wed, May 17, 2017 at 9:16 PM, Eric Blake <ebl...@redhat.com> wrote: > On 05/17/2017 12:09 PM, Stefan Hajnoczi wrote: >> diff --git a/block/io.c b/block/io.c >> index cc56e90..f0041cd 100644 >> --- a/block/io.c >> +++ b/block/io.c >> @@ -2031,9 +2031,7 @@ bdrv_rw_vmstate(BlockDriverState *bs, QEMUIOVector >> *qiov, int64_t pos, >> Coroutine *co = qemu_coroutine_create(bdrv_co_rw_vmstate_entry, >> &data); >> >> bdrv_coroutine_enter(bs, co); >> - while (data.ret == -EINPROGRESS) { >> - aio_poll(bdrv_get_aio_context(bs), true); >> - } >> + BDRV_POLL_WHILE(bs, data.ret == -EINPROGRESS); >> return data.ret; >> } > > Do we have other culprits (not necessarily for vmsave, but for other > situations), where we should be using BDRV_POLL_WHILE in separate > patches? For example, a quick grep show that at least hw/9pfs/9p.c makes > a direct call to aio_poll(,true) in a while loop.
virtio-9p doesn't use IOThread (dataplane) so it is not affected. It also doesn't use BlockDriverState so it cannot use BDRV_POLL_WHILE(). I did grep for other aio_poll() callers and didn't spot any obvious cases that need to be fixed. They tend to run in situations where this deadlock cannot occur. Stefan