[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Use-after-free during unrealize in system_reset
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] Use-after-free during unrealize in system_reset |
Date: |
Thu, 5 Jun 2014 19:18:03 +0300 |
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 (address@hidden,
> address@hidden '\021', address@hidden '\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
> (address@hidden, address@hidden,
> address@hidden "realized", address@hidden) at
> qom/qom-qobject.c:24
> #8 0x00007fd910763090 in object_property_set_bool
> (address@hidden, address@hidden,
> address@hidden "realized", address@hidden) 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
> (address@hidden, address@hidden, 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>,
> address@hidden <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
- [Qemu-devel] Use-after-free during unrealize in system_reset, Stefan Hajnoczi, 2014/06/05
- Re: [Qemu-devel] Use-after-free during unrealize in system_reset,
Michael S. Tsirkin <=
- Re: [Qemu-devel] Use-after-free during unrealize in system_reset, Stefan Hajnoczi, 2014/06/06
- Re: [Qemu-devel] Use-after-free during unrealize in system_reset, Paolo Bonzini, 2014/06/06
- Re: [Qemu-devel] Use-after-free during unrealize in system_reset, Michael S. Tsirkin, 2014/06/08
- Re: [Qemu-devel] Use-after-free during unrealize in system_reset, Paolo Bonzini, 2014/06/08
- Re: [Qemu-devel] Use-after-free during unrealize in system_reset, Michael S. Tsirkin, 2014/06/08
- Re: [Qemu-devel] Use-after-free during unrealize in system_reset, Michael S. Tsirkin, 2014/06/08
- Re: [Qemu-devel] Use-after-free during unrealize in system_reset, Paolo Bonzini, 2014/06/09
- Re: [Qemu-devel] Use-after-free during unrealize in system_reset, Michael S. Tsirkin, 2014/06/09
- Re: [Qemu-devel] Use-after-free during unrealize in system_reset, Bandan Das, 2014/06/09
- Re: [Qemu-devel] Use-after-free during unrealize in system_reset, Andreas Färber, 2014/06/11