Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 13 11月, 2018 6 次提交
    • F
      file-posix: Skip effectiveless OFD lock operations · 2996ffad
      由 Fam Zheng 提交于 
      If we know we've already locked the bytes, don't do it again; similarly
don't unlock a byte if we haven't locked it. This doesn't change the
behavior, but fixes a corner case explained below.

Libvirt had an error handling bug that an image can get its (ownership,
file mode, SELinux) permissions changed (RHBZ 1584982) by mistake behind
QEMU. Specifically, an image in use by Libvirt VM has:

    $ ls -lhZ b.img
    -rw-r--r--. qemu qemu system_u:object_r:svirt_image_t:s0:c600,c690 b.img

Trying to attach it a second time won't work because of image locking.
And after the error, it becomes:

    $ ls -lhZ b.img
    -rw-r--r--. root root system_u:object_r:virt_image_t:s0 b.img

Then, we won't be able to do OFD lock operations with the existing fd.
In other words, the code such as in blk_detach_dev:

    blk_set_perm(blk, 0, BLK_PERM_ALL, &error_abort);

can abort() QEMU, out of environmental changes.

This patch is an easy fix to this and the change is regardlessly
reasonable, so do it.
Signed-off-by: NFam Zheng <famz@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      2996ffad
    • L
      nvme: free cmbuf in nvme_exit · a883d6a0
      由 Li Qiang 提交于 
      This avoid a memory leak in unhotplug nvme device.
Signed-off-by: NLi Qiang <liq3ea@gmail.com>
Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      a883d6a0
    • L
      nvme: don't unref ctrl_mem when device unrealized · 20faf0f5
      由 Li Qiang 提交于 
      Currently, when hotplug/unhotplug nvme device, it will cause an
assert in object.c. Following is the backtrack:

ERROR:qom/object.c:981:object_unref: assertion failed: (obj->ref > 0)

Thread 2 "qemu-system-x86" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffcbd32700 (LWP 18844)]
0x00007fffdb9e4fff in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
/lib/x86_64-linux-gnu/libglib-2.0.so.0
/lib/x86_64-linux-gnu/libglib-2.0.so.0
qom/object.c:981
/home/liqiang02/qemu-upstream/qemu/memory.c:1732
/home/liqiang02/qemu-upstream/qemu/memory.c:285
util/qemu-thread-posix.c:504
/lib/x86_64-linux-gnu/libpthread.so.0

This is caused by memory_region_unref in nvme_exit.

Remove it to make the PCIdevice refcount correct.
Signed-off-by: NLi Qiang <liq3ea@gmail.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      20faf0f5
    • P
      blockdev: Consistently use snapshot_node_name in external_snapshot_prepare() · d52e1a0e
      由 Peter Maydell 提交于 
      In the function external_snapshot_prepare() we have a
BlockdevSnapshotSync struct, which has the usual combination
of has_snapshot_node_name and snapshot_node_name fields for an
optional field. We set up a local variable
        const char *snapshot_node_name =
            s->has_snapshot_node_name ? s->snapshot_node_name : NULL;

and then mostly use "if (!snapshot_node_name)" for checking
whether we have a snapshot node name. The exception is that in
one place we check s->has_snapshot_node_name instead. This
confuses Coverity (CID 1396473), which thinks it might be
possible to get here with s->has_snapshot_node_name true but
snapshot_node_name NULL, and warns that the call to
qdict_put_str() will segfault in that case.

Make the code consistent and unconfuse Coverity by using
the same check for this conditional that we do in the rest
of the surrounding code.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NAlberto Garcia <berto@igalia.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      d52e1a0e
    • Z
      blockdev: handle error on block latency histogram set error · 63d5341f
      由 zhenwei pi 提交于 
      Function block_latency_histogram_set may return error, but qapi ignore this.
This can be reproduced easily by qmp command:
virsh qemu-monitor-command INSTANCE '{"execute":"x-block-latency-histogram-set",
"arguments":{"device":"drive-virtio-disk1","boundaries":[10,200,40]}}'
In fact this command does not work, but we still get success result.

qmp_x_block_latency_histogram_set is a batch setting API, report error ASAP.
Signed-off-by: Nzhenwei pi <pizhenwei@bytedance.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      63d5341f
    • F
      file-posix: Use error API properly · db0754df
      由 Fam Zheng 提交于 
      Use error_report for situations that affect user operation (i.e.  we're
actually returning error), and warn_report/warn_report_err when some
less critical error happened but the user operation can still carry on.

For raw_normalize_devicepath, add Error parameter to propagate to
its callers.
Suggested-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NFam Zheng <famz@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      db0754df
  3. 12 11月, 2018 15 次提交
  5. 10 11月, 2018 4 次提交
  7. 09 11月, 2018 4 次提交
    • P
      Merge remote-tracking branch 'remotes/gkurz/tags/for-upstream' into staging · 160e5c22
      由 Peter Maydell 提交于 
      Fixes a potential use-after-free issue that could be triggered by a
misbehaving guest.

# gpg: Signature made Thu 08 Nov 2018 20:36:48 GMT
# gpg:                using RSA key 71D4D5E5822F73D6
# gpg: Good signature from "Greg Kurz <groug@kaod.org>"
# gpg:                 aka "Gregory Kurz <gregory.kurz@free.fr>"
# gpg:                 aka "[jpeg image of size 3330]"
# Primary key fingerprint: B482 8BAF 9431 40CE F2A3  4910 71D4 D5E5 822F 73D6

* remotes/gkurz/tags/for-upstream:
  9p: write lock path in v9fs_co_open2()
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      160e5c22
    • G
      9p: write lock path in v9fs_co_open2() · 5b76ef50
      由 Greg Kurz 提交于 
      The assumption that the fid cannot be used by any other operation is
wrong. At least, nothing prevents a misbehaving client to create a
file with a given fid, and to pass this fid to some other operation
at the same time (ie, without waiting for the response to the creation
request). The call to v9fs_path_copy() performed by the worker thread
after the file was created can race with any access to the fid path
performed by some other thread. This causes use-after-free issues that
can be detected by ASAN with a custom 9p client.

Unlike other operations that only read the fid path, v9fs_co_open2()
does modify it. It should hence take the write lock.

Cc: P J P <ppandit@redhat.com>
Reported-by: Nzhibin hu <noirfate@gmail.com>
Signed-off-by: NGreg Kurz <groug@kaod.org>
      5b76ef50
    • P
      Merge remote-tracking branch 'remotes/riscv/tags/riscv-for-master-3.1-rc1' into staging · d3c2bbb1
      由 Peter Maydell 提交于 
      A Single RISC-V Patch for 3.1-rc1

This tag contains a single patch that I'd like to target for rc1: a fix
for a memory leak that was detected by static code analysis.

There are still three patch sets that I'd like to try to get up for 3.1:

* The patch set Basian just published that contains fixes for a pair of
  issues he found when converting our port to decodetree.
* An as-of-yet-unwritten fix to the third issue that Basian pointed out.
* A fix to our fflags bug, which is currently coupled to some CSR
  refactoring that I don't think is OK for 3.1.

I'm at Plumbers next week (and I think Alistair is there too?), but I'll
try to find a way to squeeze in as much as possible.

# gpg: Signature made Thu 08 Nov 2018 16:50:27 GMT
# gpg:                using RSA key EF4CA1502CCBAB41
# gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>"
# gpg:                 aka "Palmer Dabbelt <palmer@sifive.com>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 00CE 76D1 8349 60DF CE88  6DF8 EF4C A150 2CCB AB41

* remotes/riscv/tags/riscv-for-master-3.1-rc1:
  riscv: spike: Fix memory leak in the board init
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      d3c2bbb1
    • A
      riscv: spike: Fix memory leak in the board init · 00a014ac
      由 Alistair Francis 提交于 
      Coverity caught a malloc() call that was never freed. This patch ensures
that we free the memory but also updates the allocation to use
g_strdup_printf() instead of malloc().
Signed-off-by: NAlistair Francis <alistair.francis@wdc.com>
Suggested-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NPalmer Dabbelt <palmer@sifive.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      00a014ac
  9. 08 11月, 2018 11 次提交