All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Akihiko Odaki" <odaki@rsg.ci.i.u-tokyo.ac.jp>,
	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 14:23:35 +0100	[thread overview]
Message-ID: <aMq2V0rD2Q27VXOg@redhat.com> (raw)
In-Reply-To: <aMq073aYphuFO2En@redhat.com>

On Wed, Sep 17, 2025 at 02:17:35PM +0100, Daniel P. Berrangé wrote:
> On Wed, Sep 17, 2025 at 09:24:04PM +0900, Akihiko Odaki wrote:
> > On 2025/09/17 20:57, Daniel P. Berrangé wrote:
> > > 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 ?
> > 
> > This patch series deals with the situation where the parent calls
> > object_unparent() in its instance_finalize() callback. The process of
> > finalization looks like as follows:
> > 
> > 1. The parent's reference count reaches to zero. Please note that there can
> > be remaining children that are referenced by the parent at this point.
> > 
> > 2. object_finalize() is called.
> > 
> > 2a. object_property_del_all() is called and the parent releases references
> > to its children. This is what I referred as "automatic unparenting". The
> > children without any other references will be finalized here.
> > 
> > 2b. instance_finalize() is called. Past children may be already finalized,
> > and calling object_unparent() here will cause dereferencing finalized
> > objects in that case, which should be avoided.
> 
> Oh, so these object_unparent calls run by the parent, against the child
> in fact use-after-free flaws.

Oh actually not a use-after-free since memory regions aren't directly
freed by object_finalize.


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 :|



  reply	other threads:[~2025-09-17 13:25 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 ` [PATCH v3 0/7] " Daniel P. Berrangé
2025-09-17 12:24   ` Akihiko Odaki
2025-09-17 13:17     ` Daniel P. Berrangé
2025-09-17 13:23       ` Daniel P. Berrangé [this message]
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=aMq2V0rD2Q27VXOg@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.