On Tue, Jan 09, 2018 at 01:42:08PM +0000, Stefan Hajnoczi wrote: > On Tue, Dec 19, 2017 at 04:45:48PM +0800, Peter Xu wrote: > > @@ -4071,6 +4073,9 @@ static void handle_qmp_command(JSONMessageParser > > *parser, GQueue *tokens) > > req_obj->req = req; > > req_obj->need_resume = false; > > > > + /* Protect qmp_requests and fetching its length. */ > > + qemu_mutex_lock(&mon->qmp.qmp_queue_lock); > > + > > /* > > * If OOB is not enabled on current monitor, we'll emulate the old > > * behavior that we won't process current monitor any more until > > @@ -4080,6 +4085,17 @@ static void handle_qmp_command(JSONMessageParser > > *parser, GQueue *tokens) > > if (!qmp_oob_enabled(mon)) { > > monitor_suspend(mon); > > req_obj->need_resume = true; > > + } else { > > + /* Drop the request if queue is full. */ > > + if (mon->qmp.qmp_requests->length >= QMP_REQ_QUEUE_LEN_MAX) { > > + qapi_event_send_command_dropped(id, > > + COMMAND_DROP_REASON_QUEUE_FULL, > > + NULL); > > + qobject_decref(id); > > + qobject_decref(req); > > + g_free(req_obj); > > + return; > > qmp_queue_lock is still locked! I suggest releasing the lock before > calling qapi_event_send_command_dropped().
Yes. It took me some time to rebase and move that lock out, even if so I still got one more bug... Thanks for catching it. And yes, I agree I should unlock before sending the event. -- Peter Xu