From: Kevin Wolf <kwolf@redhat.com>
To: Jeff Cody <jcody@redhat.com>
Cc: Fam Zheng <famz@redhat.com>,
qemu-block@nongnu.org, qemu-devel@nongnu.org,
Max Reitz <mreitz@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
pbonzini@redhat.com
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 0/1] block: Workaround for the iotests errors
Date: Tue, 28 Nov 2017 13:28:35 +0100 [thread overview]
Message-ID: <20171128122835.GC3703@localhost.localdomain> (raw)
In-Reply-To: <20171128114250.GB3703@localhost.localdomain>
Am 28.11.2017 um 12:42 hat Kevin Wolf geschrieben:
> Am 28.11.2017 um 06:43 hat Jeff Cody geschrieben:
> > On Tue, Nov 28, 2017 at 12:29:09AM +0100, Kevin Wolf wrote:
> > > Am 23.11.2017 um 18:57 hat Fam Zheng geschrieben:
> > > > Jeff's block job patch made the latent drain bug visible, and I find this
> > > > patch, which by itself also makes some sense, can hide it again. :) With it
> > > > applied we are at least back to the ground where patchew's iotests (make
> > > > docker-test-block@fedora) can pass.
> > > >
> > > > The real bug is that in the middle of bdrv_parent_drained_end(), bs's parent
> > > > list changes. One drained_end call before the mirror_exit() already did one
> > > > blk_root_drained_end(), a second drained_end on an updated parent node can do
> > > > another same blk_root_drained_end(), making it unbalanced with
> > > > blk_root_drained_begin(). This is shown by the following three backtraces as
> > > > captured by rr with a crashed "qemu-img commit", essentially the same as in
> > > > the failed iotest 020:
> > >
> > > My conclusion what really happens in 020 is that we have a graph like
> > > this:
> > >
> > > mirror target BB --+
> > > |
> > > v
> > > qemu-img BB -> mirror_top_bs -> overlay -> base
> > >
> > > bdrv_drained_end(base) results in it being available for requests again,
> > > so it calls bdrv_parent_drained_end() for overlay. While draining
> > > itself, the mirror job completes and changes the BdrvChild between
> > > mirror_top_bs and overlay (which is currently being drained) to point to
> > > base instead. After returning, QLIST_FOREACH() continues to iterate the
> > > parents of base instead of those of overlay, resulting in a second
> > > blk_drained_end() for the mirror target BB.
> > >
> > > This instance can be fixed relatively easily (see below) by using
> > > QLIST_FOREACH_SAFE() instead.
> > >
> > > However, I'm not sure if all problems with the graph change can be
> > > solved this way and whether we can really allow graph changes while
> > > iterating the graph for bdrv_drained_begin/end. Not allowing it would
> > > require some more serious changes to the block jobs that delays their
> > > completion until after bdrv_drain_end() has finished (not sure how to
> > > even get a callback at that point...)
> > >
> >
> > That is at least part of what is causing the segfaults that I am still
> > seeing (after your patch):
> >
> > We enter bdrv_drain_recurse(), and the BDS has been reaped:
>
> Not sure which test case this is referring to, probably 097 as that's
> the next one in your list?
>
> Anyway, test cases 097 and 176 can be fixed for me by keeping some
> additional references. This quick fix is probably not quite correct
> according to the comment in bdrv_drain_recurse() because bdrv_ref/unref
> are only allowed in the main loop thread.
>
> Also, case 141 is still failing.
As for 141, this one just hangs now because the test case sets speed=1
and so the job throttling decides to sleep for a few hours. We used to
interrupt block_job_sleep_ns(), now we don't any more. I think we need
to allow this again.
Kevin
prev parent reply other threads:[~2017-11-28 12:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-23 17:57 [Qemu-devel] [PATCH 0/1] block: Workaround for the iotests errors Fam Zheng
2017-11-23 17:57 ` [Qemu-devel] [PATCH 1/1] block: Don't poll for drain end Fam Zheng
2017-11-24 6:12 ` [Qemu-devel] [PATCH 0/1] block: Workaround for the iotests errors Jeff Cody
2017-11-24 8:41 ` Fam Zheng
2017-11-24 16:39 ` Kevin Wolf
2017-11-28 2:53 ` Fam Zheng
2017-11-27 23:29 ` Kevin Wolf
2017-11-28 0:21 ` [Qemu-devel] [Qemu-block] " John Snow
2017-11-28 5:43 ` [Qemu-devel] " Jeff Cody
2017-11-28 11:42 ` Kevin Wolf
2017-11-28 12:28 ` Kevin Wolf [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=20171128122835.GC3703@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=famz@redhat.com \
--cc=jcody@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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).