From: Markus Armbruster <armbru@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Stefan Reiter <s.reiter@proxmox.com>,
Thomas Lamprecht <t.lamprecht@proxmox.com>,
qemu-devel@nongnu.org, Wolfgang Bumiller <w.bumiller@proxmox.com>
Subject: Re: [PATCH v2] monitor/qmp: fix race on CHR_EVENT_CLOSED without OOB
Date: Thu, 08 Apr 2021 14:49:02 +0200 [thread overview]
Message-ID: <871rblaqm9.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <YG7akVvfY30Q7Cj1@merkur.fritz.box> (Kevin Wolf's message of "Thu, 8 Apr 2021 12:27:29 +0200")
Kevin Wolf <kwolf@redhat.com> writes:
> Am 08.04.2021 um 11:21 hat Markus Armbruster geschrieben:
>> Kevin Wolf <kwolf@redhat.com> writes:
>>
>> > Am 22.03.2021 um 16:40 hat Stefan Reiter geschrieben:
>> >> The QMP dispatcher coroutine holds the qmp_queue_lock over a yield
>> >> point, where it expects to be rescheduled from the main context. If a
>> >> CHR_EVENT_CLOSED event is received just then, it can race and block the
>> >> main thread on the mutex in monitor_qmp_cleanup_queue_and_resume.
>> >>
>> >> monitor_resume does not need to be called from main context, so we can
>> >> call it immediately after popping a request from the queue, which allows
>> >> us to drop the qmp_queue_lock mutex before yielding.
>> >>
>> >> Suggested-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
>> >> Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
>> >> ---
>> >> v2:
>> >> * different approach: move everything that needs the qmp_queue_lock mutex before
>> >> the yield point, instead of moving the event handling to a different context
>> >
>> > The interesting new case here seems to be that new requests could be
>> > queued and the dispatcher coroutine could be kicked before yielding.
>> > This is safe because &qmp_dispatcher_co_busy is accessed with atomics
>> > on both sides.
>> >
>> > The important part is just that the first (conditional) yield stays
>> > first, so that the aio_co_wake() in handle_qmp_command() won't reenter
>> > the coroutine while it is expecting to be reentered from somewhere else.
>> > This is still the case after the patch.
>> >
>> > Reviewed-by: Kevin Wolf <kwolf@redhat.com>
>>
>> Thanks for saving me from an ugly review headache.
>>
>> Should this go into 6.0?
>
> This is something that the responsible maintainer needs to decide.
Yes, and that's me. I'm soliciting opinions.
> If it helps you with the decision, and if I understand correctly, it is
> a regression from 5.1, but was already broken in 5.2.
It helps.
Even more helpful would be a risk assessment: what's the risk of
applying this patch now vs. delaying it?
If I understand Stefan correctly, Proxmox observed VM hangs. How
frequent are these hangs? Did they result in data corruption?
How confident do we feel about the fix?
next prev parent reply other threads:[~2021-04-08 12:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 15:40 [PATCH v2] monitor/qmp: fix race on CHR_EVENT_CLOSED without OOB Stefan Reiter
2021-04-07 13:19 ` Kevin Wolf
2021-04-08 9:21 ` Markus Armbruster
2021-04-08 10:27 ` Kevin Wolf
2021-04-08 12:49 ` Markus Armbruster [this message]
2021-04-08 13:27 ` Thomas Lamprecht
2021-04-08 14:10 ` Markus Armbruster
2021-04-09 15:30 ` Markus Armbruster
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=871rblaqm9.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=s.reiter@proxmox.com \
--cc=t.lamprecht@proxmox.com \
--cc=w.bumiller@proxmox.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).