qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [RFC 1/5] block/nbd: Fix hang in .bdrv_close()
Date: Fri, 12 Jul 2019 12:47:14 +0200	[thread overview]
Message-ID: <8ce2ce78-833e-c98f-ad3a-d44f6432ae4c@redhat.com> (raw)
In-Reply-To: <20190712092419.GB4514@dhcp-200-226.str.redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 2327 bytes --]

On 12.07.19 11:24, Kevin Wolf wrote:
> Am 11.07.2019 um 21:58 hat Max Reitz geschrieben:
>> When nbd_close() is called from a coroutine, the connection_co never
>> gets to run, and thus nbd_teardown_connection() hangs.
>>
>> This is because aio_co_enter() only puts the connection_co into the main
>> coroutine's wake-up queue, so this main coroutine needs to yield and
>> reschedule itself to let the connection_co run.
>>
>> Signed-off-by: Max Reitz <mreitz@redhat.com>
>> ---
>>  block/nbd.c | 12 +++++++++++-
>>  1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/block/nbd.c b/block/nbd.c
>> index 81edabbf35..b83b6cd43e 100644
>> --- a/block/nbd.c
>> +++ b/block/nbd.c
>> @@ -135,7 +135,17 @@ static void nbd_teardown_connection(BlockDriverState *bs)
>>      qio_channel_shutdown(s->ioc,
>>                           QIO_CHANNEL_SHUTDOWN_BOTH,
>>                           NULL);
>> -    BDRV_POLL_WHILE(bs, s->connection_co);
>> +
>> +    if (qemu_in_coroutine()) {
>> +        /* Let our caller poll and just yield until connection_co is done */
>> +        while (s->connection_co) {
>> +            aio_co_schedule(qemu_get_current_aio_context(),
>> +                            qemu_coroutine_self());
>> +            qemu_coroutine_yield();
>> +        }
> 
> Isn't this busy waiting? Why not let s->connection_co wake us up when
> it's about to terminate instead of immediately rescheduling ourselves?

Yes, it is busy waiting, but I didn’t find that bad.  The connection_co
will be invoked in basically every iteration, and once there is no
pending data, it will quit.

The answer to “why not...” of course is because it’d be more complicated.

But anyway.

Adding a new function qemu_coroutine_run_after(target) that adds
qemu_coroutine_self() to the given @target coroutine’s wake-up queue and
then using that instead of scheduling works, too, yes.

I don’t really like being responsible for coroutine code, though...

(And maybe it’d be better to make it qemu_coroutine_yield_for(target),
which does the above and then yields?)

Max

>> +    } else {
>> +        BDRV_POLL_WHILE(bs, s->connection_co);
>> +    }
>>  
>>      nbd_client_detach_aio_context(bs);
>>      object_unref(OBJECT(s->sioc));
> 
> Kevin
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-07-12 10:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-11 19:57 [Qemu-devel] [RFC 0/5] block: Generic file truncation/creation fallbacks Max Reitz
2019-07-11 19:58 ` [Qemu-devel] [RFC 1/5] block/nbd: Fix hang in .bdrv_close() Max Reitz
2019-07-12  9:24   ` Kevin Wolf
2019-07-12 10:47     ` Max Reitz [this message]
2019-07-12 11:01       ` Kevin Wolf
2019-07-12 11:09         ` Max Reitz
2019-07-12 11:23           ` Kevin Wolf
2019-07-12 11:44             ` Max Reitz
2019-07-12 12:30               ` Kevin Wolf
2019-07-11 19:58 ` [Qemu-devel] [RFC 2/5] block: Generic truncation fallback Max Reitz
2019-07-12  9:49   ` Kevin Wolf
2019-07-12 10:58     ` Max Reitz
2019-07-12 11:17       ` Kevin Wolf
2019-07-12 11:48         ` Max Reitz
2019-07-12 13:48           ` Max Reitz
2019-07-11 19:58 ` [Qemu-devel] [RFC 3/5] block: Fall back to fallback truncate function Max Reitz
2019-07-12 10:04   ` Kevin Wolf
2019-07-12 11:05     ` Max Reitz
2019-07-11 19:58 ` [Qemu-devel] [RFC 4/5] block: Generic file creation fallback Max Reitz
2019-07-11 19:58 ` [Qemu-devel] [RFC 5/5] iotests: Add test for fallback truncate/create Max Reitz

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=8ce2ce78-833e-c98f-ad3a-d44f6432ae4c@redhat.com \
    --to=mreitz@redhat.com \
    --cc=kwolf@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).