From: Markus Armbruster <armbru@redhat.com>
To: Andrey Shinkevich via <qemu-devel@nongnu.org>
Cc: kwolf@redhat.com, lvivier@redhat.com, thuth@redhat.com,
vsementsov@virtuozzo.com, qemu-block@nongnu.org, den@openvz.org,
armbru@redhat.com, mdroth@linux.vnet.ibm.com, mreitz@redhat.com,
pbonzini@redhat.com,
Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>,
dgilbert@redhat.com
Subject: Re: [PATCH v3 2/5] monitor: drain requests queue with 'channel closed' event
Date: Tue, 02 Mar 2021 14:53:29 +0100 [thread overview]
Message-ID: <87h7ltll0m.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <1606484146-913540-3-git-send-email-andrey.shinkevich@virtuozzo.com> (Andrey Shinkevich via's message of "Fri, 27 Nov 2020 16:35:43 +0300")
Andrey Shinkevich via <qemu-devel@nongnu.org> writes:
> When CHR_EVENT_CLOSED comes, the QMP requests queue may still contain
> unprocessed commands. It can happen with QMP capability OOB enabled.
> Let the dispatcher complete handling requests rest in the monitor
> queue.
>
> Signed-off-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
> ---
> monitor/qmp.c | 46 +++++++++++++++++++++-------------------------
> 1 file changed, 21 insertions(+), 25 deletions(-)
>
> diff --git a/monitor/qmp.c b/monitor/qmp.c
> index 7169366..a86ed35 100644
> --- a/monitor/qmp.c
> +++ b/monitor/qmp.c
> @@ -75,36 +75,32 @@ static void monitor_qmp_cleanup_req_queue_locked(MonitorQMP *mon)
> }
> }
>
> -static void monitor_qmp_cleanup_queue_and_resume(MonitorQMP *mon)
> +/*
> + * Let unprocessed QMP commands be handled.
> + */
> +static void monitor_qmp_drain_queue(MonitorQMP *mon)
> {
> - qemu_mutex_lock(&mon->qmp_queue_lock);
> + bool q_is_empty = false;
>
> - /*
> - * Same condition as in monitor_qmp_dispatcher_co(), but before
> - * removing an element from the queue (hence no `- 1`).
> - * Also, the queue should not be empty either, otherwise the
> - * monitor hasn't been suspended yet (or was already resumed).
> - */
> - bool need_resume = (!qmp_oob_enabled(mon) ||
> - mon->qmp_requests->length == QMP_REQ_QUEUE_LEN_MAX)
> - && !g_queue_is_empty(mon->qmp_requests);
> + while (!q_is_empty) {
> + qemu_mutex_lock(&mon->qmp_queue_lock);
> + q_is_empty = g_queue_is_empty(mon->qmp_requests);
> + qemu_mutex_unlock(&mon->qmp_queue_lock);
>
> - monitor_qmp_cleanup_req_queue_locked(mon);
> + if (!q_is_empty) {
> + if (!qatomic_xchg(&qmp_dispatcher_co_busy, true)) {
> + /* Kick the dispatcher coroutine */
> + aio_co_wake(qmp_dispatcher_co);
> + } else {
> + /* Let the dispatcher do its job for a while */
> + g_usleep(40);
> + }
> + }
> + }
>
> - if (need_resume) {
> - /*
> - * handle_qmp_command() suspended the monitor because the
> - * request queue filled up, to be resumed when the queue has
> - * space again. We just emptied it; resume the monitor.
> - *
> - * Without this, the monitor would remain suspended forever
> - * when we get here while the monitor is suspended. An
> - * unfortunately timed CHR_EVENT_CLOSED can do the trick.
> - */
> + if (qatomic_mb_read(&mon->common.suspend_cnt)) {
> monitor_resume(&mon->common);
> }
> -
> - qemu_mutex_unlock(&mon->qmp_queue_lock);
> }
>
> void qmp_send_response(MonitorQMP *mon, const QDict *rsp)
> @@ -418,7 +414,7 @@ static void monitor_qmp_event(void *opaque, QEMUChrEvent event)
> * stdio, it's possible that stdout is still open when stdin
> * is closed.
> */
> - monitor_qmp_cleanup_queue_and_resume(mon);
> + monitor_qmp_drain_queue(mon);
> json_message_parser_destroy(&mon->parser);
> json_message_parser_init(&mon->parser, handle_qmp_command,
> mon, NULL);
Before the patch: we call monitor_qmp_cleanup_queue_and_resume() to
throw away the contents of the request queue, and resume the monitor if
suspended.
Afterwards: we call monitor_qmp_drain_queue() to wait for the request
queue to drain. I think. Before we discuss the how, I have a question
the commit message should answer, but doesn't: why?
next prev parent reply other threads:[~2021-03-02 13:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-27 13:35 [PATCH v3 0/5] Increase amount of data for monitor to read Andrey Shinkevich via
2020-11-27 13:35 ` [PATCH v3 1/5] monitor: change function obsolete name in comments Andrey Shinkevich via
2021-03-02 13:45 ` Markus Armbruster
2020-11-27 13:35 ` [PATCH v3 2/5] monitor: drain requests queue with 'channel closed' event Andrey Shinkevich via
2021-03-02 13:53 ` Markus Armbruster [this message]
2021-03-02 15:25 ` Vladimir Sementsov-Ogievskiy
2021-03-02 16:32 ` Denis V. Lunev
2021-03-02 17:02 ` Vladimir Sementsov-Ogievskiy
2021-03-05 13:41 ` Markus Armbruster
2021-03-05 14:01 ` Vladimir Sementsov-Ogievskiy
2020-11-27 13:35 ` [PATCH v3 3/5] monitor: let QMP monitor track JSON message content Andrey Shinkevich via
2020-11-27 13:35 ` [PATCH v3 4/5] iotests: 129 don't check backup "busy" Andrey Shinkevich via
2021-03-02 13:45 ` Markus Armbruster
2020-11-27 13:35 ` [PATCH v3 5/5] monitor: increase amount of data for monitor to read Andrey Shinkevich via
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=87h7ltll0m.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=andrey.shinkevich@virtuozzo.com \
--cc=den@openvz.org \
--cc=dgilbert@redhat.com \
--cc=kwolf@redhat.com \
--cc=lvivier@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=vsementsov@virtuozzo.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.