From: Ed Swierk <eswierk@skyportsystems.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Fam Zheng <famz@redhat.com>, Kevin Wolf <kwolf@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Assertion failure taking external snapshot with virtio drive + iothread
Date: Mon, 20 Mar 2017 18:48:54 -0700 [thread overview]
Message-ID: <CAO_EM_=JfwBHROTZ2c3fEka1D0D0EN1BD0rrKOcNaja+drJ=mA@mail.gmail.com> (raw)
In-Reply-To: <a98bb8fd-c087-5cb2-92bc-76f255330e3d@redhat.com>
On Fri, Mar 17, 2017 at 12:27 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> And this is a fix, but I have no idea why/how it works and what else it
> may break.
>
> Patches 1 and 2 are pretty obvious and would be the first step towards
> eliminating aio_disable/enable_external altogether.
>
> However I got patch 3 more or less by trial and error, and when I
> thought I had the reasoning right I noticed this:
>
> bdrv_drained_end(state->old_bs);
>
> in external_snapshot_clean which makes no sense given the
>
> bdrv_drained_begin(bs_new);
>
> that I added to bdrv_append. So take this with a ton of salt.
>
> The basic idea is that calling child->role->drained_begin and
> child->role->drained_end is not necessary and in fact actively wrong
> when both the old and the new child should be in a drained section.
> But maybe instead it should be asserted that they are, except for the
> special case of adding or removing a child. i.e. after
>
> int drain = !!(old_bs && old_bs->quiesce_counter) - !!(new_bs && new_bs->quiesce_counter);
>
> add
>
> assert(!(drain && old_bs && new_bs));
>
> Throwing this out because it's Friday evening... Maybe Fam can pick
> it up on Monday.
I just tested this patch on top of today's master. It does make the
ctx->external_disable_cnt > 0 assertion failure on snapshot_blkdev go
away. But it seems to cause a different assertion failure when running
without an iothread, e.g.
qemu-system-x86_64 -nographic -enable-kvm -monitor
telnet:0.0.0.0:1234,server,nowait -m 1024 -object
iothread,id=iothread1 -drive file=/x/drive.qcow2,if=none,id=drive0
-device virtio-blk-pci,drive=drive0
and with the guest constantly writing to the disk with something like
while true; do echo 12345 >blah; done
Running snapshot_blkdev in the monitor repeatedly (with a new backing
file each time) triggers the following after a few tries:
qemu-system-x86_64: /x/qemu/block.c:2965: bdrv_replace_node:
Assertion `!({ typedef struct { int:(sizeof(*&from->in_flight) >
sizeof(void *)) ? -1 : 1; } qemu_build_bug_on__4
__attribute__((unused)); __atomic_load_n(&from->in_flight, 0); })'
failed.
This does not occur on today's master without this patch.
--Ed
next prev parent reply other threads:[~2017-03-21 1:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-17 16:55 [Qemu-devel] Assertion failure taking external snapshot with virtio drive + iothread Ed Swierk
2017-03-17 17:11 ` Paolo Bonzini
2017-03-17 17:15 ` Paolo Bonzini
2017-03-17 17:32 ` Ed Swierk
2017-03-17 18:10 ` Paolo Bonzini
2017-03-17 19:27 ` Paolo Bonzini
2017-03-20 21:54 ` Ed Swierk
2017-03-21 1:48 ` Ed Swierk [this message]
2017-03-21 5:26 ` Fam Zheng
2017-03-21 12:20 ` Ed Swierk
2017-03-21 12:50 ` Fam Zheng
2017-03-21 13:05 ` Ed Swierk
2017-03-22 9:19 ` Fam Zheng
2017-03-22 17:36 ` Ed Swierk
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='CAO_EM_=JfwBHROTZ2c3fEka1D0D0EN1BD0rrKOcNaja+drJ=mA@mail.gmail.com' \
--to=eswierk@skyportsystems.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.