[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 23/30] bus: do not unref hotplug handler
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH v2 23/30] bus: do not unref hotplug handler |
Date: |
Wed, 22 Feb 2017 14:04:43 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 |
On 22/02/2017 14:03, Marc-André Lureau wrote:
> Hi
>
> On Wed, Feb 22, 2017 at 3:39 PM Paolo Bonzini <address@hidden
> <mailto:address@hidden>> wrote:
>
>
>
> On 21/02/2017 15:14, Marc-André Lureau wrote:
> > Apparently, none of the bus owner give a reference to the hotplug
> > handler property, do not unref it on bus release.
> >
> > Furthermore, a bus is allowed to be its own hotplug handler, which can
> > be seen in qbus_set_bus_hotplug_handler() function. However, in this
> > case, the reference can't be given to the property, or this will
> create
> > a cyclic dependency and the bus will never be free.
> >
> > Each bus owner should manage the lifecycle of the hotplug handler.
> >
> > Signed-off-by: Marc-André Lureau <address@hidden
> <mailto:address@hidden>>
>
> Almost all qbus_set_hotplug_handler callers are using it to set the
> parent device (that is, the "adapter" or "bridge", whatever you want to
> call it) as the hotplug handler.
>
> The exception is piix4_update_bus_hotplug. This one is the only case
> where OBJ_PROP_LINK_UNREF_ON_RELEASE would be right. Luckily, there
> _is_ a reference to that device somewhere else to keep it alive, namely
> in /machine's acpi-device prop. So this case is a bit hacky (not your
> fault) but works as well. In addition the PIIX4_PM device is not
> hot(un)pluggable.
>
> I understand you agree with my change, correct?
Yes.
> Can you please add a comment to piix4_update_bus_hotplug explaining that
> the PIIX4PMState cannot outlive the PCIBus, because /machine keeps
> it alive?
>
>
> Do you mean PCIBus cannot outlive PIIX4PMState? (ie the PIIX4PMState
> will always be there since it's linked from /machine)
Yes (or just because it's not unpluggable).
Paolo
- [Qemu-devel] [PATCH v2 18/30] tests: fix e1000-test leak, (continued)
- [Qemu-devel] [PATCH v2 18/30] tests: fix e1000-test leak, Marc-André Lureau, 2017/02/21
- [Qemu-devel] [PATCH v2 19/30] tests: fix i440fx-test leaks, Marc-André Lureau, 2017/02/21
- [Qemu-devel] [PATCH v2 20/30] tests: fix e1000e leaks, Marc-André Lureau, 2017/02/21
- [Qemu-devel] [PATCH v2 21/30] tests: fix virtio-scsi-test leak, Marc-André Lureau, 2017/02/21
- [Qemu-devel] [PATCH v2 22/30] tests: fix virtio-9p-test leaks, Marc-André Lureau, 2017/02/21
- [Qemu-devel] [PATCH v2 23/30] bus: do not unref hotplug handler, Marc-André Lureau, 2017/02/21
- [Qemu-devel] [PATCH v2 24/30] usb: replace handle_destroy with unrealize, Marc-André Lureau, 2017/02/21
- [Qemu-devel] [PATCH v2 26/30] tests: allows to run single test in usb-hcd-ehci-test, Marc-André Lureau, 2017/02/21
- [Qemu-devel] [PATCH v2 25/30] usb: release the created buses, Marc-André Lureau, 2017/02/21
- [Qemu-devel] [PATCH v2 27/30] tests: fix usb-test leaks, Marc-André Lureau, 2017/02/21
- [Qemu-devel] [PATCH v2 28/30] tests: add specialized device_find function, Marc-André Lureau, 2017/02/21