From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, "Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] Use-after-free during unrealize in system_reset
Date: Thu, 5 Jun 2014 19:18:03 +0300 [thread overview]
Message-ID: <20140605161803.GB11292@redhat.com> (raw)
In-Reply-To: <CAJSP0QXUsWO1R1pFfiiDNS-gitK=0ufTxvFG7=BKkGTc00c7dA@mail.gmail.com>
On Thu, Jun 05, 2014 at 05:31:45PM +0200, Stefan Hajnoczi wrote:
> qemu-iotests ./check -qcow2 067 is entering an infinite loop during
> system_reset. This failure is a non-deterministic use-after-free and
> the infinite loop happens maybe 1/3 of the time.
This patch makes it fail deterministically.
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 22fe5ee..6815fad 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -790,6 +790,7 @@ static void pci_config_alloc(PCIDevice *pci_dev)
static void pci_config_free(PCIDevice *pci_dev)
{
g_free(pci_dev->config);
+ pci_dev->config = NULL;
g_free(pci_dev->cmask);
g_free(pci_dev->wmask);
g_free(pci_dev->w1cmask);
> Michael Tsirkin found that pci_unregister_device() is called before
> pci_find_capability_list() since the parent is destroyed before the
> child.
>
> Looks like a qdev/qom issue. Any takers?
With virtio, virtio pci is the bus and devices are children
behind it.
I suspect that bus is unrealized before children.
> Thread 1 (Thread 0x7fd9104fda80 (LWP 11716)):
> #0 pci_find_capability_list (pdev=0x7fd912e94fc0, prev_p=<synthetic
> pointer>, cap_id=17 '\021') at hw/pci/pci.c:1839
> #1 pci_del_capability (pdev=pdev@entry=0x7fd912e94fc0,
> cap_id=cap_id@entry=17 '\021', size=size@entry=12 '\f') at
> hw/pci/pci.c:2079
> #2 0x00007fd9106d8e46 in msix_uninit (dev=0x7fd912e94fc0,
> table_bar=0x7fd912e953b0, pba_bar=0x7fd912e953b0) at hw/pci/msix.c:357
> #3 0x00007fd9106d8f13 in msix_uninit_exclusive_bar
> (dev=0x7fd912e94fc0) at hw/pci/msix.c:377
> #4 0x00007fd9107e6dcf in virtio_device_unrealize (dev=0x7fd912e958a8,
> errp=0x7fff20cb8370) at /home/stefanha/qemu/hw/virtio/virtio.c:1199
> #5 0x00007fd910692f93 in device_set_realized (obj=<optimized out>,
> value=<optimized out>, errp=0x0) at hw/core/qdev.c:847
> #6 0x00007fd910761c2e in property_set_bool (obj=0x7fd912e958a8,
> v=<optimized out>, opaque=0x7fd912e96ad0, name=<optimized out>,
> errp=0x0)
> at qom/object.c:1421
> #7 0x00007fd9107641b7 in object_property_set_qobject
> (obj=obj@entry=0x7fd912e958a8, value=value@entry=0x7fd912e6bd70,
> name=name@entry=0x7fd9108a9a3a "realized", errp=errp@entry=0x0) at
> qom/qom-qobject.c:24
> #8 0x00007fd910763090 in object_property_set_bool
> (obj=obj@entry=0x7fd912e958a8, value=value@entry=false,
> name=name@entry=0x7fd9108a9a3a "realized", errp=errp@entry=0x0) at
> qom/object.c:883
> #9 0x00007fd910691958 in device_unparent (obj=0x7fd912e958a8) at
> hw/core/qdev.c:946
> #10 0x00007fd910762d41 in object_unparent (obj=0x7fd912e958a8) at
> qom/object.c:400
> #11 0x00007fd910691db8 in bus_unparent (obj=<optimized out>) at
> hw/core/qdev.c:547
> #12 0x00007fd910762d41 in object_unparent (obj=0x7fd912e95830) at
> qom/object.c:400
> #13 0x00007fd910691809 in device_unparent (obj=0x7fd912e94fc0) at
> hw/core/qdev.c:950
> #14 0x00007fd910762d41 in object_unparent (obj=0x7fd912e94fc0) at
> qom/object.c:400
> #15 0x00007fd91066b7b6 in acpi_pcihp_eject_slot
> (s=s@entry=0x7fd912e8e048, bsel=bsel@entry=0, slots=<optimized out>)
> at hw/acpi/pcihp.c:139
> #16 0x00007fd91066b862 in acpi_pcihp_update_hotplug_bus (bsel=0,
> s=0x7fd912e8e048) at hw/acpi/pcihp.c:152
> #17 acpi_pcihp_update (s=0x7fd912e8e048) at hw/acpi/pcihp.c:176
> #18 acpi_pcihp_reset (s=0x7fd912e8e048) at hw/acpi/pcihp.c:182
> #19 0x00007fd910797abd in qemu_devices_reset () at vl.c:1893
> ---Type <return> to continue, or q <return> to quit---
> #20 qemu_system_reset (report=<optimized out>) at vl.c:1906
> #21 0x00007fd91060bfaf in main_loop_should_exit () at vl.c:2041
> #22 main_loop () at vl.c:2081
> #23 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized
> out>) at vl.c:4565
>
> Thread 2 (Thread 0x7fd8f9c83700 (LWP 11722)):
> #0 __lll_lock_wait () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
> #1 0x00007fd90deea59c in _L_cond_lock_789 () from /lib64/libpthread.so.0
> #2 0x00007fd90deea431 in __pthread_mutex_cond_lock
> (mutex=0x7fd9110f6c00 <qemu_global_mutex>) at
> ../nptl/pthread_mutex_lock.c:79
> #3 0x00007fd90dee4db0 in pthread_cond_wait@@GLIBC_2.3.2 () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:259
> #4 0x00007fd9108837f9 in qemu_cond_wait (cond=<optimized out>,
> mutex=mutex@entry=0x7fd9110f6c00 <qemu_global_mutex>) at
> util/qemu-thread-posix.c:135
> #5 0x00007fd91079c8d8 in qemu_tcg_cpu_thread_fn (arg=<optimized out>)
> at /home/stefanha/qemu/cpus.c:943
> #6 0x00007fd90dee0f33 in start_thread (arg=0x7fd8f9c83700) at
> pthread_create.c:309
> #7 0x00007fd906b23ded in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
next prev parent reply other threads:[~2014-06-05 16:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-05 15:31 [Qemu-devel] Use-after-free during unrealize in system_reset Stefan Hajnoczi
2014-06-05 16:18 ` Michael S. Tsirkin [this message]
2014-06-06 9:03 ` Stefan Hajnoczi
2014-06-06 9:52 ` Paolo Bonzini
2014-06-08 10:46 ` Michael S. Tsirkin
2014-06-08 14:40 ` Paolo Bonzini
2014-06-08 14:52 ` Michael S. Tsirkin
2014-06-08 14:52 ` Michael S. Tsirkin
2014-06-09 7:51 ` Paolo Bonzini
2014-06-09 8:15 ` Michael S. Tsirkin
2014-06-09 17:02 ` Bandan Das
2014-06-11 12:03 ` Andreas Färber
2014-06-11 12:24 ` Paolo Bonzini
2014-06-11 15:51 ` Bandan Das
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140605161803.GB11292@redhat.com \
--to=mst@redhat.com \
--cc=afaerber@suse.de \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).