[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] [PATCH 2/3] block: use BDRV_POLL_WHILE() i
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [Qemu-block] [PATCH 2/3] block: use BDRV_POLL_WHILE() in bdrv_rw_vmstate() |
Date: |
Thu, 18 May 2017 09:05:09 +0100 |
On Wed, May 17, 2017 at 9:16 PM, Eric Blake <address@hidden> 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
[Qemu-devel] [PATCH 3/3] migration: avoid recursive AioContext locking in save_vmstate(), Stefan Hajnoczi, 2017/05/17
Re: [Qemu-devel] [PATCH 0/3] block: fix 'savevm' hang with -object iothread, Paolo Bonzini, 2017/05/17