From: Kevin Wolf <kwolf@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Stefan Reiter <s.reiter@proxmox.com>,
qemu-devel@nongnu.org, Wolfgang Bumiller <w.bumiller@proxmox.com>,
Thomas Lamprecht <t.lamprecht@proxmox.com>
Subject: Re: [PATCH v2] monitor/qmp: fix race on CHR_EVENT_CLOSED without OOB
Date: Thu, 8 Apr 2021 12:27:29 +0200 [thread overview]
Message-ID: <YG7akVvfY30Q7Cj1@merkur.fritz.box> (raw)
In-Reply-To: <87lf9tces9.fsf@dusky.pond.sub.org>
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.
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.
Kevin
next prev parent reply other threads:[~2021-04-08 10:28 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 [this message]
2021-04-08 12:49 ` Markus Armbruster
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=YG7akVvfY30Q7Cj1@merkur.fritz.box \
--to=kwolf@redhat.com \
--cc=armbru@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 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.