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
