From: "Michael Qiu" <qiudayu@huayun.com>
To: "Vladimir Sementsov-Ogievskiy" <vsementsov@virtuozzo.com>,
liangpeng10@huawei.com
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
"jsnow@redhat.com" <jsnow@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
"mreitz@redhat.com" <mreitz@redhat.com>
Subject: Re:Re: [PATCH v4] blockjob: Fix crash with IOthread when block commit after snapshot
Date: Mon, 1 Feb 2021 21:09:32 +0800 (CST) [thread overview]
Message-ID: <42519db5.35bf.1775db66d57.Coremail.qiudayu@huayun.com> (raw)
In-Reply-To: <8041055c-b542-ad14-c8be-6266679d5142@virtuozzo.com>
[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]
Peng,
In my analysis, the root casue should be the lock: aio_context, qemu main thread do an unnecessary release/aquire action,
That's why IO thread could get the lock it shouldn't hold at this stage.
Thanks,
Michael
At 2021-02-01 20:44:00, "Vladimir Sementsov-Ogievskiy" <vsementsov@virtuozzo.com> wrote:
>Hi!
>
>01.02.2021 15:07, Peng Liang wrote:
>> Hi,
>>
>> I encountered the problem months ago too. Could we move the creation of
>> the block job (block_job_create) before appending the new bs to
>> mirror_top_bs (bdrv_append) as I wrote in [*]? I found that after
>> bdrv_append, qemu will use mirror_top_bs to do write. And when writing,
>> qemu will use bs->opaque, which maybe NULL.
>>
>> [*]
>> http://patchwork.ozlabs.org/project/qemu-devel/patch/20200826131910.1879079-1-liangpeng10@huawei.com/
>>
>
>In this patch you create job over original bs, when jobs are normally created over job-filter bs. I don't know is it wrong, but it at least requires some research, and probably the code that removes the filter should be adjusted somehow. Also, you make bs->opaque be non-zero. But still, job is not fully initialized, and some another problem may occur. So, do we create job prior to filter insertion or after it, parallel io requests to bs should not interrupt mirror_start_job(). So I think Michael's patch is closer to real problem to fix.
>
>
>--
>Best regards,
>Vladimir
[-- Attachment #2: Type: text/html, Size: 2210 bytes --]
prev parent reply other threads:[~2021-02-01 13:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-25 12:07 [PATCH] Fix crash with IOthread when block commit after snapshot 08005325
2021-01-26 3:11 ` [PATCH v2] " 08005325
2021-01-26 3:25 ` [PATCH v3] " 08005325
2021-01-28 1:30 ` [PATCH v4] blockjob: " 08005325
2021-01-28 5:16 ` 仇大玉
2021-02-01 2:40 ` 仇大玉
2021-02-01 10:27 ` Vladimir Sementsov-Ogievskiy
2021-02-01 11:26 ` 仇大玉
2021-02-01 12:07 ` Peng Liang
2021-02-01 12:44 ` Vladimir Sementsov-Ogievskiy
2021-02-01 13:09 ` Michael Qiu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42519db5.35bf.1775db66d57.Coremail.qiudayu@huayun.com \
--to=qiudayu@huayun.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=liangpeng10@huawei.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).