From: Markus Armbruster <armbru@redhat.com>
To: Jason Andryuk <jandryuk@gmail.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [PATCH] qmp: Reset mon->commands on CHR_EVENT_CLOSED
Date: Wed, 13 Nov 2019 13:40:45 +0100 [thread overview]
Message-ID: <878sok2ble.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20191106130309.6737-1-jandryuk@gmail.com> (Jason Andryuk's message of "Wed, 6 Nov 2019 08:03:09 -0500")
Jason Andryuk <jandryuk@gmail.com> writes:
> Currently, mon->commands is uninitialized until CHR_EVENT_OPENED where
> it is set to &qmp_cap_negotiation_commands. After capability
> negotiation, it is set to &qmp_commands. If the chardev is closed,
> CHR_EVENT_CLOSED, mon->commands remains as &qmp_commands. Only once the
> chardev is re-opened with CHR_EVENT_OPENED, is it reset to
> &qmp_cap_negotiation_commands.
>
> monitor_qapi_event_emit compares mon->commands to
> &qmp_cap_negotiation_commands, and skips sending events when they are
> equal.
The check's purpose is to ensure we don't send events in capabilities
negotiation mode, i.e. between connect and a successful qmp_capabilities
command.
> In the case of a closed chardev, QMP events are still sent down
> to the closed chardev which needs to drop them.
True, but I wonder how this can happen. Can you explain?
> Set mon->commands to &qmp_cap_negotiation_commands for CHR_EVENT_CLOSED
> to stop sending events. Setting for the CHR_EVENT_OPENED case remains
> since that is how mon->commands is set for a newly opened connections.
>
> Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
> ---
> monitor/qmp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/monitor/qmp.c b/monitor/qmp.c
> index 9d9e5d8b27..5e2073c5eb 100644
> --- a/monitor/qmp.c
> +++ b/monitor/qmp.c
> @@ -333,6 +333,7 @@ static void monitor_qmp_event(void *opaque, int event)
case CHR_EVENT_CLOSED:
/*
* Note: this is only useful when the output of the chardev
* backend is still open. For example, when the backend is
* stdio, it's possible that stdout is still open when stdin
> * is closed.
> */
> monitor_qmp_cleanup_queues(mon);
> + mon->commands = &qmp_cap_negotiation_commands;
> json_message_parser_destroy(&mon->parser);
> json_message_parser_init(&mon->parser, handle_qmp_command,
> mon, NULL);
Patchew reports this loses SHUTDOWN events. Local testing confirms it
does. Simplified reproducer:
$ for ((i=0; i<100; i++)); do printf '{"execute": "qmp_capabilities"}\n{"execute": "quit"}' | upstream-qemu -S -display none -qmp stdio; done | grep -c SHUTDOWN
84
In this test, the SHUTDOWN event was lost 16 out of 100 times.
Its emission obviously races with the assignment you add.
The comment preceding it provides a clue: after CHR_EVENT_CLOSED, we
know the input direction is gone, and we duly clean up that part of the
monitor. But the output direction may or may not be gone, so we don't
touch it. Your assignment touches it. This is not the correct spot.
I can't tell you offhand where the correct spot is. Perhaps Marc-André
can.
next prev parent reply other threads:[~2019-11-13 12:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-06 13:03 [PATCH] qmp: Reset mon->commands on CHR_EVENT_CLOSED Jason Andryuk
2019-11-06 14:52 ` Marc-André Lureau
2019-11-06 15:10 ` Jason Andryuk
2019-11-07 1:08 ` no-reply
2019-11-07 16:08 ` Jason Andryuk
2019-11-13 12:40 ` Markus Armbruster [this message]
2019-11-13 13:18 ` Marc-André Lureau
2019-11-13 13:37 ` Jason Andryuk
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=878sok2ble.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=jandryuk@gmail.com \
--cc=marcandre.lureau@redhat.com \
--cc=qemu-devel@nongnu.org \
/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.