All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-block@nongnu.org, mreitz@redhat.com, stefanha@redhat.com,
	jcody@redhat.com, famz@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH for-2.11 1/4] Revert "coroutine: abort if we try to schedule or enter a pending coroutine"
Date: Tue, 28 Nov 2017 17:37:25 +0100	[thread overview]
Message-ID: <20171128163725.GG3703@localhost.localdomain> (raw)
In-Reply-To: <00b2dbda-e7a1-2fc4-b7ca-e60c0ef08a95@redhat.com>

Am 28.11.2017 um 17:18 hat Paolo Bonzini geschrieben:
> On 28/11/2017 16:43, Kevin Wolf wrote:
> > This reverts commit 6133b39f3c36623425a6ede9e89d93175fde15cd.
> > 
> > The commit checked conditions that would expose a bug, but there is no
> > real reason to forbid them apart from the bug, which we'll fix in a
> > minute.
> > 
> > In particular, reentering a coroutine during co_aio_sleep_ns() is fine;
> > the function is explicitly written to allow this.
> 
> This is true.
> 
> > aio_co_schedule() can indeed conflict with direct coroutine invocations,
> > but this is exactky what we want to fix, so remove that check again,
> > too.
> 
> I'm not sure this is a good idea, as I answered in patch 3.
> 
> It can also conflict badly with another aio_co_schedule().  Your patch
> here removes the assertion in this case, and patch 3 makes it easier to
> get into the situation where two aio_co_schedule()s conflict with each
> other.

I don't see how they conflict. If the second aio_co_schedule() comes
before the coroutine is actually entered, they are effectively simply
merged into a single one. Which is exactly what was intended.

> For example, say you have a coroutine that calls aio_co_schedule on
> itself, like
> 
> 	while (true) {
> 		aio_co_schedule(qemu_get_current_aio_context(),
> 				qemu_coroutine_self());
> 	}
> 
> If somebody else calls qemu_coroutine_enter on this coroutine, *that* is
> the bug.  These patches would just cause some random corruption or
> (perhaps worse) hang.

Obviously not every coroutine is made to be reentered from multiple
places, so for some cases it just might not make a whole lot of sense.
Coroutines that are made for it generally are one of the types I
explained in the commit message of patch 3.

But anyway, how would this cause corruption or a hang (apart from the
fact that this example doesn't have any state that could even be
corrupted)? The external qemu_coroutine_enter() would just replace the
scheduled coroutine call, so the coroutine wouldn't even notice that it
was called from qemu_coroutine_enter() rather than its own scheduled
call.

Kevin

  reply	other threads:[~2017-11-28 16:37 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-28 15:43 [Qemu-devel] [PATCH for-2.11 0/4] Fix qemu-iotests failures Kevin Wolf
2017-11-28 15:43 ` [Qemu-devel] [PATCH for-2.11 1/4] Revert "coroutine: abort if we try to schedule or enter a pending coroutine" Kevin Wolf
2017-11-28 16:00   ` Jeff Cody
2017-11-28 16:18   ` Paolo Bonzini
2017-11-28 16:37     ` Kevin Wolf [this message]
2017-11-28 17:01       ` Paolo Bonzini
2017-11-28 17:19         ` Kevin Wolf
2017-11-28 17:33           ` Jeff Cody
2017-11-28 17:35           ` Paolo Bonzini
2017-11-28 15:43 ` [Qemu-devel] [PATCH for-2.11 2/4] Revert "blockjob: do not allow coroutine double entry or entry-after-completion" Kevin Wolf
2017-11-28 16:00   ` Jeff Cody
2017-11-28 15:43 ` [Qemu-devel] [PATCH for-2.11 3/4] coroutine: Cancel aio_co_schedule() on direct entry Kevin Wolf
2017-11-28 16:09   ` Jeff Cody
2017-11-28 16:14   ` Paolo Bonzini
2017-11-28 16:28     ` Kevin Wolf
2017-11-28 16:42       ` Jeff Cody
2017-11-28 16:51         ` Paolo Bonzini
2017-11-28 17:09           ` Jeff Cody
2017-11-28 17:14             ` Paolo Bonzini
2017-11-28 17:03         ` Kevin Wolf
2017-11-28 16:45       ` Paolo Bonzini
2017-11-28 16:30   ` Fam Zheng
2017-11-28 16:46   ` Eric Blake
2017-11-28 15:43 ` [Qemu-devel] [PATCH for-2.11 4/4] block: Expect graph changes in bdrv_parent_drained_begin/end Kevin Wolf
2017-11-28 16:10   ` Jeff Cody
2017-11-28 15:56 ` [Qemu-devel] [PATCH for-2.11 0/4] Fix qemu-iotests failures Jeff Cody
2017-11-28 16:00 ` Stefan Hajnoczi

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=20171128163725.GG3703@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 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.