From: Stefan Hajnoczi <stefanha@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
Fam Zheng <famz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] vl: pause vcpus before stopping iothreads
Date: Thu, 1 Feb 2018 11:07:48 +0000 [thread overview]
Message-ID: <20180201110748.GC5783@stefanha-x1.localdomain> (raw)
In-Reply-To: <20180131143127.GC3598@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2345 bytes --]
On Wed, Jan 31, 2018 at 03:31:27PM +0100, Kevin Wolf wrote:
> Am 31.01.2018 um 14:56 hat Stefan Hajnoczi geschrieben:
> > On Tue, Jan 30, 2018 at 05:54:56PM +0100, Kevin Wolf wrote:
> > > Am 30.01.2018 um 16:38 hat Stefan Hajnoczi geschrieben:
> > > > Commit dce8921b2baaf95974af8176406881872067adfa ("iothread: Stop threads
> > > > before main() quits") introduced iothread_stop_all() to avoid the
> > > > following virtio-scsi assertion failure:
> > > >
> > > > assert(blk_get_aio_context(d->conf.blk) == s->ctx);
> > > >
> > > > Back then the assertion failed because when bdrv_close_all() made
> > > > d->conf.blk NULL, blk_get_aio_context() returned the global AioContext
> > > > instead of s->ctx.
> > > >
> > > > The same assertion can still fail today when vcpus submit new I/O
> > > > requests after iothread_stop_all() has moved the BDS to the global
> > > > AioContext.
> > > >
> > > > This patch hardens the iothread_stop_all() approach by pausing vcpus
> > > > before calling iothread_stop_all().
> > > >
> > > > Note that the assertion failure is a race condition. It is not possible
> > > > to reproduce it reliably.
> > > >
> > > > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > >
> > > Does pausing the vcpus actually make sure that the iothread isn't active
> > > any more, or do we still have a small window where the vcpu is already
> > > stopped, but the iothread is still processing requests?
> > >
> > > Essentially, I think the bdrv_set_aio_context() in iothread_stop_all()
> > > does either not have any effect, or if it does have an effect, it's
> > > wrong. You can't just force an in-use BDS into a different AioContext
> > > when the user that set the AioContext is still there.
> > >
> > > At the very least, do we need a blk_drain_all() before stopping the
> > > iothreads?
> >
> > bdrv_set_aio_context() contains aio_disable_external() +
> > bdrv_parent_drained_begin() + bdrv_drain(bs). This should complete all
> > requests, even those sitting in a descriptor ring that hasn't been
> > processed yet.
>
> Ah, yes. Not very obvious, so I wouldn't mind a comment, but you can
> have my R-b either way then:
>
> Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Thanks for the review! I have sent v2 with a comment for you to review.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
prev parent reply other threads:[~2018-02-01 11:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-30 15:38 [Qemu-devel] [PATCH] vl: pause vcpus before stopping iothreads Stefan Hajnoczi
2018-01-30 16:54 ` Kevin Wolf
2018-01-31 13:56 ` Stefan Hajnoczi
2018-01-31 14:31 ` Kevin Wolf
2018-02-01 11:07 ` Stefan Hajnoczi [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=20180201110748.GC5783@stefanha-x1.localdomain \
--to=stefanha@redhat.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--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 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).