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. 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>
signature.asc
Description: PGP signature
