[PULL 0/1] Monitor patches for 2019-11-19

[PULL 0/1] Monitor patches for 2019-11-19

[Markus Armbruster]

I'd like to propose this bug fix for -rc2.  Certain usage of QMP can
leave the monitor permanently wedged (depends on event timing).
Libvirt does not use it this way as far as I know.  I understand it
affects other applications.  It's not a a regression in 4.2.

If it's too late for fixing it in 4.2, we'll punt to 5.0 with cc:
qemu-stable.

The following changes since commit a5c2a235103ab366ad5318636ec138e52c6dcfa4:

  Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging (2019-11-18 17:06:17 +0000)

are available in the Git repository at:

  git://repo.or.cz/qemu/armbru.git tags/pull-monitor-2019-11-19

for you to fetch changes up to 2895aaa139b3f916b3650ca516b35dceb9c0d4c4:

  monitor/qmp: resume monitor when clearing its queue (2019-11-19 08:21:47 +0100)

----------------------------------------------------------------
Monitor patches for 2019-11-19

----------------------------------------------------------------
Wolfgang Bumiller (1):
      monitor/qmp: resume monitor when clearing its queue

 monitor/qmp.c | 36 +++++++++++++++++++++++++++++++-----
 1 file changed, 31 insertions(+), 5 deletions(-)

-- 
2.21.0

[PULL 1/1] monitor/qmp: resume monitor when clearing its queue

[Markus Armbruster]

From: Wolfgang Bumiller <w.bumiller@proxmox.com>

When a monitor's queue is filled up in handle_qmp_command()
it gets suspended. It's the dispatcher bh's job currently to
resume the monitor, which it does after processing an event
from the queue. However, it is possible for a
CHR_EVENT_CLOSED event to be processed before before the bh
is scheduled, which will clear the queue without resuming
the monitor, thereby preventing the dispatcher from reaching
the resume() call.
Any new connections to the qmp socket will be accept()ed and
show the greeting, but will not respond to any messages sent
afterwards (as they will not be read from the
still-suspended socket).
Fix this by resuming the monitor when clearing a queue which
was filled up.

Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Message-Id: <20191115085914.21287-1-w.bumiller@proxmox.com>
---
 monitor/qmp.c | 36 +++++++++++++++++++++++++++++++-----
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/monitor/qmp.c b/monitor/qmp.c
index 9d9e5d8b27..b67a8e7d1f 100644
--- a/monitor/qmp.c
+++ b/monitor/qmp.c
@@ -75,10 +75,35 @@ static void monitor_qmp_cleanup_req_queue_locked(MonitorQMP *mon)
     }
 }
 
-static void monitor_qmp_cleanup_queues(MonitorQMP *mon)
+static void monitor_qmp_cleanup_queue_and_resume(MonitorQMP *mon)
 {
     qemu_mutex_lock(&mon->qmp_queue_lock);
+
+    /*
+     * Same condition as in monitor_qmp_bh_dispatcher(), 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);
+
     monitor_qmp_cleanup_req_queue_locked(mon);
+
+    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.
+         */
+        monitor_resume(&mon->common);
+    }
+
     qemu_mutex_unlock(&mon->qmp_queue_lock);
 }
 
@@ -263,9 +288,10 @@ static void handle_qmp_command(void *opaque, QObject *req, Error *err)
 
     /*
      * Suspend the monitor when we can't queue more requests after
-     * this one.  Dequeuing in monitor_qmp_bh_dispatcher() will resume
-     * it.  Note that when OOB is disabled, we queue at most one
-     * command, for backward compatibility.
+     * this one.  Dequeuing in monitor_qmp_bh_dispatcher() or
+     * monitor_qmp_cleanup_queue_and_resume() will resume it.
+     * Note that when OOB is disabled, we queue at most one command,
+     * for backward compatibility.
      */
     if (!qmp_oob_enabled(mon) ||
         mon->qmp_requests->length == QMP_REQ_QUEUE_LEN_MAX - 1) {
@@ -332,7 +358,7 @@ static void monitor_qmp_event(void *opaque, int event)
          * stdio, it's possible that stdout is still open when stdin
          * is closed.
          */
-        monitor_qmp_cleanup_queues(mon);
+        monitor_qmp_cleanup_queue_and_resume(mon);
         json_message_parser_destroy(&mon->parser);
         json_message_parser_init(&mon->parser, handle_qmp_command,
                                  mon, NULL);
-- 
2.21.0

Re: [PULL 0/1] Monitor patches for 2019-11-19

[Peter Maydell]

On Tue, 19 Nov 2019 at 09:05, Markus Armbruster <armbru@redhat.com> wrote:
>
> I'd like to propose this bug fix for -rc2.  Certain usage of QMP can
> leave the monitor permanently wedged (depends on event timing).
> Libvirt does not use it this way as far as I know.  I understand it
> affects other applications.  It's not a a regression in 4.2.
>
> If it's too late for fixing it in 4.2, we'll punt to 5.0 with cc:
> qemu-stable.
>
> The following changes since commit a5c2a235103ab366ad5318636ec138e52c6dcfa4:
>
>   Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging (2019-11-18 17:06:17 +0000)
>
> are available in the Git repository at:
>
>   git://repo.or.cz/qemu/armbru.git tags/pull-monitor-2019-11-19
>
> for you to fetch changes up to 2895aaa139b3f916b3650ca516b35dceb9c0d4c4:
>
>   monitor/qmp: resume monitor when clearing its queue (2019-11-19 08:21:47 +0100)
>
> ----------------------------------------------------------------
> Monitor patches for 2019-11-19
>
> ----------------------------------------------------------------
> Wolfgang Bumiller (1):
>       monitor/qmp: resume monitor when clearing its queue


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.2
for any user-visible changes.

-- PMM