Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 09 2月, 2019 1 次提交
  3. 06 2月, 2019 1 次提交
  5. 05 2月, 2019 8 次提交
  7. 04 2月, 2019 1 次提交
  9. 01 2月, 2019 14 次提交
  11. 31 1月, 2019 3 次提交
    • M
      iotests: Allow 147 to be run concurrently · 908b3016
      由 Max Reitz 提交于 
      To do this, we need to allow creating the NBD server on various ports
instead of a single one (which may not even work if you run just one
instance, because something entirely else might be using that port).

So we just pick a random port in [32768, 32768 + 1024) and try to create
a server there.  If that fails, we just retry until something sticks.

For the IPv6 test, we need a different range, though (just above that
one).  This is because "localhost" resolves to both 127.0.0.1 and ::1.
This means that if you bind to it, it will bind to both, if possible, or
just one if the other is already in use.  Therefore, if the IPv6 test
has already taken [::1]:some_port and we then try to take
localhost:some_port, that will work -- only the second server will be
bound to 127.0.0.1:some_port alone and not [::1]:some_port in addition.
So we have two different servers on the same port, one for IPv4 and one
for IPv6.

But when we then try to connect to the server through
localhost:some_port, we will always end up at the IPv6 one (as long as
it is up), and this may not be the one we want.

Thus, we must make sure not to create an IPv6-only NBD server on the
same port as a normal "dual-stack" NBD server -- which is done by using
distinct port ranges, as explained above.
Signed-off-by: NMax Reitz <mreitz@redhat.com>
Message-id: 20181221234750.23577-4-mreitz@redhat.com
Reviewed-by: NJohn Snow <jsnow@redhat.com>
Signed-off-by: NMax Reitz <mreitz@redhat.com>
      908b3016
    • M
      iotests: Bind qemu-nbd to localhost in 147 · dfadac9a
      由 Max Reitz 提交于 
      By default, qemu-nbd binds to 0.0.0.0.  However, we then proceed to
connect to "localhost".  Usually, this works out fine; but if this test
is run concurrently, some other test function may have bound a different
server to ::1 (on the same port -- you can bind different serves to the
same port, as long as one is on IPv4 and the other on IPv6).

So running qemu-nbd works, it can bind to 0.0.0.0:NBD_PORT.  But
potentially a concurrent test has successfully taken [::1]:NBD_PORT.  In
this case, trying to connect to "localhost" will lead us to the IPv6
instance, where we do not want to end up.

Fix this by just binding to "localhost".  This will make qemu-nbd error
out immediately and not give us cryptic errors later.

(Also, it will allow us to just try a different port as of a future
patch.)
Signed-off-by: NMax Reitz <mreitz@redhat.com>
Message-id: 20181221234750.23577-3-mreitz@redhat.com
Reviewed-by: NJohn Snow <jsnow@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NMax Reitz <mreitz@redhat.com>
      dfadac9a
    • M
      iotests.py: Add qemu_nbd_pipe() · e1e6eccd
      由 Max Reitz 提交于 
      In some cases, we may want to deal with qemu-nbd errors (e.g. by
launching it in a different configuration until it no longer throws
any).  In that case, we do not want its output ending up in the test
output.

It may still be useful for handling the error, though, so add a new
function that works basically like qemu_nbd(), only that it returns the
qemu-nbd output instead of making it end up in the log.  In contrast to
qemu_img_pipe(), it does still return the exit code as well, though,
because that is even more important for error handling.
Signed-off-by: NMax Reitz <mreitz@redhat.com>
Message-id: 20181221234750.23577-2-mreitz@redhat.com
Reviewed-by: NJohn Snow <jsnow@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NMax Reitz <mreitz@redhat.com>
      e1e6eccd
  13. 29 1月, 2019 4 次提交
  15. 25 1月, 2019 3 次提交
  17. 24 1月, 2019 4 次提交
    • C
      json: Fix % handling when not interpolating · bbc0586c
      由 Christophe Fergeau 提交于 
      Commit 8bca4613 added support for %% in json strings when interpolating,
but in doing so broke handling of % when not interpolating.

When parse_string() is fed a string token containing '%', it skips the
'%' regardless of ctxt->ap, i.e. even it's not interpolating.  If the
'%' is the string's last character, it fails an assertion.  Else, it
"merely" swallows the '%'.

Fix parse_string() to handle '%' specially only when interpolating.

To gauge the bug's impact, let's review non-interpolating users of this
parser, i.e. code passing NULL context to json_message_parser_init():

* tests/check-qjson.c, tests/test-qobject-input-visitor.c,
  tests/test-visitor-serialization.c

  Plenty of tests, but we still failed to cover the buggy case.

* monitor.c: QMP input

* qga/main.c: QGA input

* qobject_from_json():

  - qobject-input-visitor.c: JSON command line option arguments of
    -display and -blockdev

    Reproducer: -blockdev '{"%"}'

  - block.c: JSON pseudo-filenames starting with "json:"

    Reproducer: https://bugzilla.redhat.com/show_bug.cgi?id=1668244#c3

  - block/rbd.c: JSON key pairs

    Pseudo-filenames starting with "rbd:".

Command line, QMP and QGA input are trusted.

Filenames are trusted when they come from command line, QMP or HMP.
They are untrusted when they come from from image file headers.
Example: QCOW2 backing file name.  Note that this is *not* the security
boundary between host and guest.  It's the boundary between host and an
image file from an untrusted source.

Neither failing an assertion nor skipping a character in a filename of
your choice looks exploitable.  Note that we don't support compiling
with NDEBUG.

Fixes: 8bca4613
Cc: qemu-stable@nongnu.org
Signed-off-by: NChristophe Fergeau <cfergeau@redhat.com>
Message-Id: <20190102140535.11512-1-cfergeau@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Tested-by: NRichard W.M. Jones <rjones@redhat.com>
[Commit message extended to discuss impact]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      bbc0586c
    • D
      io: ensure UNIX client doesn't unlink server socket · 73564c40
      由 Daniel P. Berrangé 提交于 
      The qio_channel_socket_close method for was mistakenly unlinking the
UNIX server socket, even if the channel was a client connection. This
was not noticed with chardevs, since they never call close, but with the
VNC server, this caused the VNC server socket to be deleted after the
first client quit.

The qio_channel_socket_close method also needlessly reimplemented the
logic that already exists in socket_listen_cleanup(). Just call that
method directly, for listen sockets only.

This fixes a regression introduced in QEMU 3.0.0 with

  commit d66f78e1
  Author: Pavel Balaev <mail@void.so>
  Date:   Mon May 21 19:17:35 2018 +0300

    Delete AF_UNIX socket after close

Fixes launchpad #1795100
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      73564c40
    • S
      iotests: add 238 for throttling tgm unregister iothread segfault · 202277f4
      由 Stefan Hajnoczi 提交于 
      Hot-unplug a scsi-hd using an iothread.  The previous patch fixes a
segfault in this scenario.

This patch adds a regression test.
Suggested-by: NAlberto Garcia <berto@igalia.com>
Suggested-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NAlberto Garcia <berto@igalia.com>
Message-id: 20190114133257.30299-3-stefanha@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      202277f4
    • M
      qapi: Eliminate indirection through qmp_event_get_func_emit() · a9529100
      由 Markus Armbruster 提交于 
      The qapi_event_send_FOO() functions emit events like this:

    QMPEventFuncEmit emit;

    emit = qmp_event_get_func_emit();
    if (!emit) {
        return;
    }

    qmp = qmp_event_build_dict("FOO");
    [put event arguments into @qmp...]

    emit(QAPI_EVENT_FOO, qmp);

The value of qmp_event_get_func_emit() depends only on the program:

* In qemu-system-FOO, it's always monitor_qapi_event_queue.

* In tests/test-qmp-event, it's always event_test_emit.

* In all other programs, it's always null.

This is exactly the kind of dependence the linker is supposed to
resolve; we don't actually need an indirection.

Note that things would fall apart if we linked more than one QAPI
schema into a single program: each set of qapi_event_send_FOO() uses
its own event enumeration, yet they share a single emit function.
Which takes the event enumeration as an argument.  Which one if
there's more than one?

More seriously: how does this work even now?  qemu-system-FOO wants
QAPIEvent, and passes a function taking that to
qmp_event_set_func_emit().  test-qmp-event wants test_QAPIEvent, and
passes a function taking that to qmp_event_set_func_emit().

It works by type trickery, of course:

    typedef void (*QMPEventFuncEmit)(unsigned event, QDict *dict);

    void qmp_event_set_func_emit(QMPEventFuncEmit emit);

    QMPEventFuncEmit qmp_event_get_func_emit(void);

We use unsigned instead of the enumeration type.  Relies on both
enumerations boiling down to unsigned, which happens to be true for
the compilers we use.

Clean this up as follows:

* Generate qapi_event_send_FOO() that call PREFIX_qapi_event_emit()
  instead of the value of qmp_event_set_func_emit().

* Generate a prototype for PREFIX_qapi_event_emit() into
  qapi-events.h.

* PREFIX_ is empty for qapi/qapi-schema.json, and test_ for
  tests/qapi-schema/qapi-schema-test.json.  It's qga_ for
  qga/qapi-schema.json, and doc-good- for
  tests/qapi-schema/doc-good.json, but those don't define any events.

* Rename monitor_qapi_event_queue() to qapi_event_emit() instead of
  passing it to qmp_event_set_func_emit().  This takes care of
  qemu-system-FOO.

* Rename event_test_emit() to test_qapi_event_emit() instead of
  passing it to qmp_event_set_func_emit().  This takes care of
  tests/test-qmp-event.

* Add a qapi_event_emit() that does nothing to stubs/monitor.c.  This
  takes care of all other programs that link code emitting QMP events.

* Drop qmp_event_set_func_emit(), qmp_event_get_func_emit().
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20181218182234.28876-3-armbru@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
[Commit message typos fixed]
      a9529100
  19. 23 1月, 2019 1 次提交