Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 12 11月, 2018 5 次提交
  3. 10 11月, 2018 4 次提交
  5. 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
  7. 08 11月, 2018 26 次提交
  9. 07 11月, 2018 1 次提交
    • P
      util/qemu-thread-posix: Fix qemu_thread_atexit* for OSX · a458774a
      由 Peter Maydell 提交于 
      Our current implementation of qemu_thread_atexit* is broken on OSX.
This is because it works by cerating a piece of thread-specific
data with pthread_key_create() and using the destructor function
for that data to run the notifier function passed to it by
the caller of qemu_thread_atexit_add(). The expected use case
is that the caller uses a __thread variable as the notifier,
and uses the callback to clean up information that it is
keeping per-thread in __thread variables.

Unfortunately, on OSX this does not work, because on OSX
a __thread variable may be destroyed (freed) before the
pthread_key_create() destructor runs. (POSIX imposes no
ordering constraint here; the OSX implementation happens
to implement __thread variables in terms of pthread_key_create((),
whereas Linux uses different mechanisms that mean the __thread
variables will still be present when the pthread_key_create()
destructor is run.)

Fix this by switching to a scheme similar to the one qemu-thread-win32
uses for qemu_thread_atexit: keep the thread's notifiers on a
__thread variable, and run the notifiers on calls to
qemu_thread_exit() and on return from the start routine passed
to qemu_thread_start(). We do this with the pthread_cleanup_push()
API.

We take advantage of the qemu_thread_atexit_add() API
permission not to run thread notifiers on process exit to
avoid having to special case the main thread.
Suggested-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-Id: <20181105135538.28025-3-peter.maydell@linaro.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      a458774a