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 <pet...@redhat.com> > > --- > > 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 <stefa...@redhat.com> Thanks for reviewing, -- Peter Xu
