Re: [Qemu-devel] [PATCH v3] monitor: let cur_mon be per-thread

[Peter Xu]

On Mon, Apr 16, 2018 at 04:37:48PM +0800, Stefan Hajnoczi wrote:
> On Thu, Apr 12, 2018 at 02:11:08PM +0800, Peter Xu wrote:
> > In the future the monitor iothread may be accessing the cur_mon as
> > well (via monitor_qmp_dispatch_one()).  Before we introduce a real
> > Out-Of-Band command, let's convert the cur_mon variable to be a
> > per-thread variable to make sure there won't be a race between threads.
> >
> > Note that thread variables are not initialized to a valid value when new
> > thread is created.  However for our case we don't need to set it up,
> > since the cur_mon variable is only used in such a pattern:
> > 
> >   old_mon = cur_mon;
> >   cur_mon = xxx;
> >   (do something, read cur_mon if necessary in the stack)
> >   cur_mon = old_mon;
> > 
> > It plays a role as stack variable, so no need to be initialized at all.
> > We only need to make sure the variable won't be changed unexpectedly by
> > other threads.
> > 
> > Signed-off-by: Peter Xu <address@hidden>
> > ---
> > v3:
> > - fix code style warning from patchew
> > v2:
> > - drop qemu-thread changes
> > ---
> >  include/monitor/monitor.h | 2 +-
> >  monitor.c                 | 2 +-
> >  stubs/monitor.c           | 2 +-
> >  tests/test-util-sockets.c | 2 +-
> >  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> The Monitor object is not fully thread-safe, so although the correct
> cur_mon is now accessible, code may still be unsafe.  For example,
> monitor_get_fd(cur_mon, ...) is not thread-safe and must not be used by
> OOB commands.

IMHO things like monitor_get_fd() should only be called in QMP
context, so there should always be a monitor_qmp_dispatch_one() in the
stack already (no matter whether it is in main thread or the monitor
iothread), which means that cur_mon should have been setup.  So IMHO
it's a programming error if monitor_get_fd() is called without correct
cur_mon setup after this patch.

> 
> Future OOB commands need to know which monitor.h APIs are safe to call,
> otherwise bugs are likely.  Please send a follow up patch to address
> this (e.g. doc comments, locking where needed, etc).
> 
> Reviewed-by: Stefan Hajnoczi <address@hidden>

Thanks for reviewing,

-- 
Peter Xu