From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Cc: qemu-devel@nongnu.org,
"Alex Williamson" <alex.williamson@redhat.com>,
"Cédric Le Goater" <clg@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Peter Xu" <peterx@redhat.com>,
"David Hildenbrand" <david@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Helge Deller" <deller@gmx.de>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"John Snow" <jsnow@redhat.com>,
qemu-block@nongnu.org, "Keith Busch" <kbusch@kernel.org>,
"Klaus Jensen" <its@irrelevant.dk>,
"Jesper Devantier" <foss@defmacro.it>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Nicholas Piggin" <npiggin@gmail.com>,
qemu-ppc@nongnu.org, "John Levon" <john.levon@nutanix.com>,
"Thanos Makatos" <thanos.makatos@nutanix.com>,
"Yanan Wang" <wangyanan55@huawei.com>,
"BALATON Zoltan" <balaton@eik.bme.hu>,
"Jiaxun Yang" <jiaxun.yang@flygoat.com>,
"Daniel Henrique Barboza" <danielhb413@gmail.com>,
"David Gibson" <david@gibson.dropbear.id.au>,
"Harsh Prateek Bora" <harshpb@linux.ibm.com>,
"Alexey Kardashevskiy" <aik@ozlabs.ru>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Fabiano Rosas" <farosas@suse.de>,
"Thomas Huth" <thuth@redhat.com>,
"Laurent Vivier" <lvivier@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Aurelien Jarno" <aurelien@aurel32.net>,
"Aleksandar Rikalo" <arikalo@gmail.com>,
"Max Filippov" <jcmvbkbc@gmail.com>,
"Hervé Poussineau" <hpoussin@reactos.org>,
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
"Artyom Tarasenko" <atar4qemu@gmail.com>,
"Alistair Francis" <alistair@alistair23.me>,
"Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>,
"Bin Meng" <bmeng.cn@gmail.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Anthony PERARD" <anthony@xenproject.org>,
"Paul Durrant" <paul@xen.org>,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 0/7] Do not unparent in instance_finalize()
Date: Wed, 17 Sep 2025 12:57:31 +0100 [thread overview]
Message-ID: <aMqiK5SaeBJlSa_h@redhat.com> (raw)
In-Reply-To: <20250917-use-v3-0-72c2a6887c6c@rsg.ci.i.u-tokyo.ac.jp>
On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
> Based-on: <cover.1751493467.git.balaton@eik.bme.hu>
> ("[PATCH v2 00/14] hw/pci-host/raven clean ups")
>
> Supersedes: <20240829-memory-v1-1-ac07af2f4fa5@daynix.com>
> ("[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@rsg.ci.i.u-tokyo.ac.jp>
> ---
> 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@rsg.ci.i.u-tokyo.ac.jp
>
> 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@eik.bme.hu/
> 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@eik.bme.hu/
> - Link to v1: https://lore.kernel.org/qemu-devel/20250906-use-v1-0-c51caafd1eb7@rsg.ci.i.u-tokyo.ac.jp
>
> ---
> 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@rsg.ci.i.u-tokyo.ac.jp>
>
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 :|
next prev parent reply other threads:[~2025-09-17 11:58 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-17 10:13 [PATCH v3 0/7] Do not unparent in instance_finalize() Akihiko Odaki
2025-09-17 10:13 ` [PATCH v3 1/7] docs/devel: " Akihiko Odaki
2025-09-17 16:24 ` Daniel P. Berrangé
2025-09-18 20:03 ` Peter Xu
2025-09-18 20:11 ` Peter Xu
2025-09-19 10:46 ` Akihiko Odaki
2025-09-17 10:13 ` [PATCH v3 2/7] vfio/pci: " Akihiko Odaki
2025-09-17 16:26 ` Daniel P. Berrangé
2025-09-17 10:13 ` [PATCH v3 3/7] hw/core/register: " Akihiko Odaki
2025-09-17 16:26 ` Daniel P. Berrangé
2025-09-17 10:13 ` [PATCH v3 4/7] hv-balloon: " Akihiko Odaki
2025-09-17 16:28 ` Daniel P. Berrangé
2025-09-17 10:13 ` [PATCH v3 5/7] hw/sd/sdhci: " Akihiko Odaki
2025-09-17 16:31 ` Daniel P. Berrangé
2025-09-17 10:13 ` [PATCH v3 6/7] vfio: " Akihiko Odaki
2025-09-17 16:32 ` Daniel P. Berrangé
2025-09-17 10:13 ` [PATCH v3 7/7] hw/xen: " Akihiko Odaki
2025-09-17 16:33 ` Daniel P. Berrangé
2025-09-17 11:57 ` Daniel P. Berrangé [this message]
2025-09-17 12:24 ` [PATCH v3 0/7] " Akihiko Odaki
2025-09-17 13:17 ` Daniel P. Berrangé
2025-09-17 13:23 ` Daniel P. Berrangé
2025-09-18 19:58 ` Peter Xu
2025-09-18 14:03 ` Peter Xu
2025-09-18 15:29 ` BALATON Zoltan
2025-09-18 16:20 ` Peter Xu
2025-09-18 18:23 ` Peter Xu
2025-09-19 10:49 ` Akihiko Odaki
2025-09-23 8:08 ` Paolo Bonzini
2025-09-24 4:57 ` Akihiko Odaki
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=aMqiK5SaeBJlSa_h@redhat.com \
--to=berrange@redhat.com \
--cc=aik@ozlabs.ru \
--cc=alex.bennee@linaro.org \
--cc=alex.williamson@redhat.com \
--cc=alistair@alistair23.me \
--cc=anthony@xenproject.org \
--cc=arikalo@gmail.com \
--cc=atar4qemu@gmail.com \
--cc=aurelien@aurel32.net \
--cc=balaton@eik.bme.hu \
--cc=bmeng.cn@gmail.com \
--cc=clg@redhat.com \
--cc=danielhb413@gmail.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=deller@gmx.de \
--cc=edgar.iglesias@gmail.com \
--cc=eduardo@habkost.net \
--cc=farosas@suse.de \
--cc=foss@defmacro.it \
--cc=harshpb@linux.ibm.com \
--cc=hpoussin@reactos.org \
--cc=its@irrelevant.dk \
--cc=jcmvbkbc@gmail.com \
--cc=jiaxun.yang@flygoat.com \
--cc=john.levon@nutanix.com \
--cc=jsnow@redhat.com \
--cc=kbusch@kernel.org \
--cc=kraxel@redhat.com \
--cc=lvivier@redhat.com \
--cc=maciej.szmigiero@oracle.com \
--cc=marcandre.lureau@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=mst@redhat.com \
--cc=npiggin@gmail.com \
--cc=odaki@rsg.ci.i.u-tokyo.ac.jp \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=sstabellini@kernel.org \
--cc=thanos.makatos@nutanix.com \
--cc=thuth@redhat.com \
--cc=wangyanan55@huawei.com \
--cc=xen-devel@lists.xenproject.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.