Skip to content

Commit 2895aaa

Browse files
BlubMarkus Armbruster
authored and
Markus Armbruster
committed
monitor/qmp: resume monitor when clearing its queue
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 <[email protected]> Message-Id: <[email protected]>
1 parent a5c2a23 commit 2895aaa

File tree

1 file changed

+31
-5
lines changed

1 file changed

+31
-5
lines changed

monitor/qmp.c

+31-5
Original file line numberDiff line numberDiff line change
@@ -75,10 +75,35 @@ static void monitor_qmp_cleanup_req_queue_locked(MonitorQMP *mon)
7575
}
7676
}
7777

78-
static void monitor_qmp_cleanup_queues(MonitorQMP *mon)
78+
static void monitor_qmp_cleanup_queue_and_resume(MonitorQMP *mon)
7979
{
8080
qemu_mutex_lock(&mon->qmp_queue_lock);
81+
82+
/*
83+
* Same condition as in monitor_qmp_bh_dispatcher(), but before
84+
* removing an element from the queue (hence no `- 1`).
85+
* Also, the queue should not be empty either, otherwise the
86+
* monitor hasn't been suspended yet (or was already resumed).
87+
*/
88+
bool need_resume = (!qmp_oob_enabled(mon) ||
89+
mon->qmp_requests->length == QMP_REQ_QUEUE_LEN_MAX)
90+
&& !g_queue_is_empty(mon->qmp_requests);
91+
8192
monitor_qmp_cleanup_req_queue_locked(mon);
93+
94+
if (need_resume) {
95+
/*
96+
* handle_qmp_command() suspended the monitor because the
97+
* request queue filled up, to be resumed when the queue has
98+
* space again. We just emptied it; resume the monitor.
99+
*
100+
* Without this, the monitor would remain suspended forever
101+
* when we get here while the monitor is suspended. An
102+
* unfortunately timed CHR_EVENT_CLOSED can do the trick.
103+
*/
104+
monitor_resume(&mon->common);
105+
}
106+
82107
qemu_mutex_unlock(&mon->qmp_queue_lock);
83108
}
84109

@@ -263,9 +288,10 @@ static void handle_qmp_command(void *opaque, QObject *req, Error *err)
263288

264289
/*
265290
* Suspend the monitor when we can't queue more requests after
266-
* this one. Dequeuing in monitor_qmp_bh_dispatcher() will resume
267-
* it. Note that when OOB is disabled, we queue at most one
268-
* command, for backward compatibility.
291+
* this one. Dequeuing in monitor_qmp_bh_dispatcher() or
292+
* monitor_qmp_cleanup_queue_and_resume() will resume it.
293+
* Note that when OOB is disabled, we queue at most one command,
294+
* for backward compatibility.
269295
*/
270296
if (!qmp_oob_enabled(mon) ||
271297
mon->qmp_requests->length == QMP_REQ_QUEUE_LEN_MAX - 1) {
@@ -332,7 +358,7 @@ static void monitor_qmp_event(void *opaque, int event)
332358
* stdio, it's possible that stdout is still open when stdin
333359
* is closed.
334360
*/
335-
monitor_qmp_cleanup_queues(mon);
361+
monitor_qmp_cleanup_queue_and_resume(mon);
336362
json_message_parser_destroy(&mon->parser);
337363
json_message_parser_init(&mon->parser, handle_qmp_command,
338364
mon, NULL);

0 commit comments

Comments
 (0)