Re: [Qemu-devel] [RFC v6 22/27] qmp: isolate responses into io thread

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2111 bytes --]

On Fri, Jan 12, 2018 at 02:44:55PM +0800, Peter Xu wrote:
> 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,

This is a case where out-of-band code depends on a mutex that non-OOB
code is used.  According to the documentation added in this patch series
all critical sections must also follow the OOB code rules.

Adding this comment informs people working with the code to follow OOB
code rules.  It certainly is safer than leaving this assumption
undocumented.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]