|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3 0/7] Do not unparent in instance_finalize()
On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
> Based-on: <cover.1751493467.git.balaton@xxxxxxxxxx>
> ("[PATCH v2 00/14] hw/pci-host/raven clean ups")
>
> Supersedes: <20240829-memory-v1-1-ac07af2f4fa5@xxxxxxxxxx>
> ("[PATCH] docs/devel: Prohibit calling object_unparent() for memory region")
>
> Children are automatically unparented so manually unparenting is
> unnecessary.
Where is automatic unparenting you're referring to being done ?
> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callback will refer to objects that are already unparented, which
> is semantically incorrect.
IIUC, object_property_add_child will acquire a reference on
the child, and object_property_del_child (and thus
object_unparent) will release that reference.
The 'object_finalize' method, and thus 'instance_finalize'
callback, won't be invoked until the last reference is
dropped on the object in question.
IOW, it should be impossible for 'object_finalize' to ever
run, as long as the child has a parent set.
So if we're in the 'finalize' then 'object_unparent' must
be a no-op as the child must already have no references
held and thus no parent.
IOW, the reason to remove 'object_unparent' calls from
finalize is surely because they do nothing at all,
rather than this talk about callbacks being run at the
wrong time ?
>
> Signed-off-by: Akihiko Odaki <odaki@xxxxxxxxxxxxxxxxxxxxxx>
> ---
> Changes in v3:
> - Added patches to remove other object_unparent() calls in
> instance_finalize().
> - Dropped patch "qdev: Automatically delete memory subregions" and the
> succeeding patches to avoid Ccing many.
> - Link to v2:
> https://lore.kernel.org/qemu-devel/20250915-use-v2-0-f4c7ff13bfe9@xxxxxxxxxxxxxxxxxxxxxx
>
> Changes in v2:
> - Added a reference to "[PATCH] docs/devel: Prohibit calling
> object_unparent() for memory region", which does something similar to
> patch "docs/devel: Do not unparent in instance_finalize()" but I
> forgot I sent it in the past.
> - Fixed a typo in patch
> "docs/devel: Do not unparent in instance_finalize()" and
> "[PATCH 02/22] vfio/pci: Do not unparent in instance_finalize()".
> - Dropped patches to move address_space_init() calls; I intend to
> QOM-ify to fix memory leaks automatically as discussed in the
> following thread:
>
> https://lore.kernel.org/qemu-devel/cd21698f-db77-eb75-6966-d559fdcab835@xxxxxxxxxx/
> But the QOM-ification will be big so I'll send it as a separate
> series.
> - Rebased on top of "[PATCH v2 00/14] hw/pci-host/raven clean ups".
> https://lore.kernel.org/qemu-devel/cover.1751493467.git.balaton@xxxxxxxxxx/
> - Link to v1:
> https://lore.kernel.org/qemu-devel/20250906-use-v1-0-c51caafd1eb7@xxxxxxxxxxxxxxxxxxxxxx
>
> ---
> Akihiko Odaki (7):
> docs/devel: Do not unparent in instance_finalize()
> vfio/pci: Do not unparent in instance_finalize()
> hw/core/register: Do not unparent in instance_finalize()
> hv-balloon: hw/core/register: Do not unparent in instance_finalize()
> hw/sd/sdhci: Do not unparent in instance_finalize()
> vfio: Do not unparent in instance_finalize()
> hw/xen: Do not unparent in instance_finalize()
>
> docs/devel/memory.rst | 19 ++++++-------------
> hw/core/register.c | 1 -
> hw/hyperv/hv-balloon.c | 12 +-----------
> hw/sd/sdhci.c | 4 ----
> hw/vfio/pci-quirks.c | 9 +--------
> hw/vfio/pci.c | 4 ----
> hw/vfio/region.c | 3 ---
> hw/xen/xen_pt_msi.c | 11 +----------
> 8 files changed, 9 insertions(+), 54 deletions(-)
> ---
> base-commit: e101d33792530093fa0b0a6e5f43e4d8cfe4581e
> change-id: 20250906-use-37ecc903a9e0
>
> Best regards,
> --
> Akihiko Odaki <odaki@xxxxxxxxxxxxxxxxxxxxxx>
>
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |