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>

Attachment: signature.asc
Description: PGP signature

Reply via email to