On Tue, Jan 09, 2018 at 02:24:35PM +0000, Stefan Hajnoczi wrote:
> On Tue, Dec 19, 2017 at 04:45:52PM +0800, Peter Xu wrote:
> > +static void monitor_qmp_bh_responder(void *opaque)
> > +{
> > + QMPResponse response;
> > +
> > + while (true) {
> > + response = monitor_qmp_response_pop_one();
> > + if (!response.data) {
> > + break;
> > + }
> > + monitor_json_emitter_raw(response.mon, response.data);
>
> Have you audited all mon->out_lock users to ensure that guest memory is
> never touched while the lock is held?
>
> If guest memory is touched then the main loop could be blocked due to
> postcopy and when the IOThread executes monitor_qmp_bh_responder() ->
> monitor_json_emitter_raw() -> monitor_puts() it will also hang!
Yes, I am mostly certain that it never touches guest memory. IMHO
it's a pure lock for monitor's output buffer since day one of its
occurence in 6cff3e8594c.
An extreme case I can think of is when someone wants to dump some data
from guest memory in QMP (I suspect who will use it though...). In
that case we will still be safe, since the guest memory access should
be happening in g_strdup_vprintf() rather than monitor_puts(), so even
if it happens we will hang at g_strdup_vprintf() without the lock taken.
>
> Please add a comment above the out_lock declaration letting users know
> that they must not touch guest memory while holding the lock.
I'm not sure whether adding a comment like this for the lock would be
a bit strange, but I agree it should be better than nothing. Thanks,
--
Peter Xu
