[Qemu-commits] [qemu/qemu] 25b1ef: qapi: Make 'allow-oob' optional in SchemaInfoComma...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 25b1ef31db30a7dace4d3a485f0a3b3c7285a795
      
https://github.com/qemu/qemu/commit/25b1ef31db30a7dace4d3a485f0a3b3c7285a795
  Author: Markus Armbruster <address@hidden>
  Date:   2018-07-23 (Mon, 23 Jul 2018)

  Changed paths:
    M qapi/introspect.json
    M scripts/qapi/introspect.py

  Log Message:
  -----------
  qapi: Make 'allow-oob' optional in SchemaInfoCommand

Making 'allow-oob' optional in SchemaInfoCommand permits omitting it
in the common case.  Shrinks query-qmp-schema's output from 122.1KiB
to 118.6KiB for me.

Note that out-of-band execution is still experimental (you have to
configure the monitor with x-oob=on to use it).

Signed-off-by: Markus Armbruster <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Peter Xu <address@hidden>


  Commit: 62aa1d887ff9fc76adb488d31447d126a78f4b8f
      
https://github.com/qemu/qemu/commit/62aa1d887ff9fc76adb488d31447d126a78f4b8f
  Author: Peter Xu <address@hidden>
  Date:   2018-07-23 (Mon, 23 Jul 2018)

  Changed paths:
    M include/monitor/monitor.h
    M monitor.c
    M stubs/monitor.c
    M tests/test-util-sockets.c

  Log Message:
  -----------
  monitor: Fix unsafe sharing of @cur_mon among threads

@cur_mon is null unless the main thread is running monitor code, either
HMP code within monitor_read(), or QMP code within
monitor_qmp_dispatch().

Use of @cur_mon outside the main thread is therefore unsafe.

Most of its uses are in monitor command handlers.  These run in the main
thread.

However, there are also uses hiding elsewhere, such as in
error_vprintf(), and thus error_report(), making these functions unsafe
outside the main thread.  No such unsafe uses are known at this time.
Regardless, this is an unnecessary trap.  It's an ancient trap, though.

More recently, commit cf869d53172 "qmp: support out-of-band (oob)
execution" spiced things up: the monitor I/O thread assigns to @cur_mon
when executing commands out-of-band.  Having two threads save, set and
restore @cur_mon without synchronization is definitely unsafe.  We can
end up with @cur_mon null while the main thread runs monitor code, or
non-null while it runs non-monitor code.

We could fix this by making the I/O thread not mess with @cur_mon, but
that would leave the trap armed and ready.

Instead, make @cur_mon thread-local.  It's now reliably null unless the
thread is running monitor code.

Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
[peterx: update subject and commit message written by Markus]
Reviewed-by: Markus Armbruster <address@hidden>
Signed-off-by: Peter Xu <address@hidden>
Message-Id: <address@hidden>


  Commit: 9ba7dd14355bb7957680d5ef764471ab102df099
      
https://github.com/qemu/qemu/commit/9ba7dd14355bb7957680d5ef764471ab102df099
  Author: Peter Maydell <address@hidden>
  Date:   2018-07-23 (Mon, 23 Jul 2018)

  Changed paths:
    M include/monitor/monitor.h
    M monitor.c
    M qapi/introspect.json
    M scripts/qapi/introspect.py
    M stubs/monitor.c
    M tests/test-util-sockets.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2018-07-23' into 
staging

QAPI and monitor patches for 2018-07-23 (3.0.0-rc2)

# gpg: Signature made Mon 23 Jul 2018 14:08:37 BST
# gpg:                using RSA key 3870B400EB918653
# gpg: Good signature from "Markus Armbruster <address@hidden>"
# gpg:                 aka "Markus Armbruster <address@hidden>"
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867  4E5F 3870 B400 EB91 8653

* remotes/armbru/tags/pull-qapi-2018-07-23:
  monitor: Fix unsafe sharing of @cur_mon among threads
  qapi: Make 'allow-oob' optional in SchemaInfoCommand

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/55b1f14cefcb...9ba7dd14355b
      **NOTE:** This service been marked for deprecation: 
https://developer.github.com/changes/2018-04-25-github-services-deprecation/

      Functionality will be removed from GitHub.com on January 31st, 2019.