qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Fam Zheng <famz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Stefan Weil <sw@weilnetz.de>,
	qemu-stable@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	pbonzini@redhat.com, lersek@redhat.com, slp@redhat.com
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v3 2/2] aio: Do aio_notify_accept only during blocking aio_poll
Date: Mon, 10 Sep 2018 11:59:14 +0800	[thread overview]
Message-ID: <20180910035914.GA21370@lemon.usersys.redhat.com> (raw)
In-Reply-To: <20180907155101.GA31915@localhost.localdomain>

On Fri, 09/07 17:51, Kevin Wolf wrote:
> Am 09.08.2018 um 15:22 hat Fam Zheng geschrieben:
> > Furthermore, blocking aio_poll is only allowed on home thread
> > (in_aio_context_home_thread), because otherwise two blocking
> > aio_poll()'s can steal each other's ctx->notifier event and cause
> > hanging just like described above.
> 
> It's good to have this assertion now at least, but after digging into
> some bugs, I think in fact that any aio_poll() (even non-blocking) is
> only allowed in the home thread: At least one reason is that if you run
> it from a different thread, qemu_get_current_aio_context() returns the
> wrong AioContext in any callbacks called by aio_poll(). Anything else
> using TLS can have similar problems.
> 
> One instance where this matters is fixed/worked around by Sergio's
> "util/async: use qemu_aio_coroutine_enter in co_schedule_bh_cb". We
> wouldn't even need that patch if we could make sure that aio_poll() is
> never called from the wrong thread. This would feel more robust.
> 
> I'll fix the aio_poll() calls in drain (the AIO_WAIT_WHILE() ones are
> already fine, the rest by removing them). After that,
> bdrv_set_aio_context() is still problematic, but the rest should be
> okay. Hopefully we can use the tighter assertion then.

Fully agree with you.

Fam

  reply	other threads:[~2018-09-10  3:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-09 13:22 [Qemu-devel] [PATCH v3 0/2] Fix aio_notify_accept() Fam Zheng
2018-08-09 13:22 ` [Qemu-devel] [PATCH v3 1/2] aio-posix: Don't count ctx->notifier as progress when polling Fam Zheng
2018-08-09 13:22 ` [Qemu-devel] [PATCH v3 2/2] aio: Do aio_notify_accept only during blocking aio_poll Fam Zheng
2018-09-07 15:51   ` [Qemu-devel] [Qemu-block] " Kevin Wolf
2018-09-10  3:59     ` Fam Zheng [this message]
2018-08-14  2:50 ` [Qemu-devel] [PATCH v3 0/2] Fix aio_notify_accept() Fam Zheng
2018-08-14  6:27   ` Paolo Bonzini

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=20180910035914.GA21370@lemon.usersys.redhat.com \
    --to=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=lersek@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=slp@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=sw@weilnetz.de \
    /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).