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>
Cc: qemu-devel@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
	"Manos Pitsidianakis" <manos.pitsidianakis@linaro.org>,
	qemu-rust@nongnu.org, "Peter Xu" <peterx@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@mailo.com>,
	"Alberto Garcia" <berto@igalia.com>,
	"Kevin Wolf" <kwolf@redhat.com>,
	"Hanna Reitz" <hreitz@redhat.com>,
	qemu-block@nongnu.org
Subject: Re: [PATCH 2/2] qom: Manage references to embedded child objects
Date: Mon, 15 Jun 2026 09:12:38 +0100	[thread overview]
Message-ID: <ai-z14dMCK33_pis@redhat.com> (raw)
In-Reply-To: <20260615-embedded-v1-2-bb0c65bf126c@rsg.ci.i.u-tokyo.ac.jp>

On Mon, Jun 15, 2026 at 01:11:07PM +0900, Akihiko Odaki wrote:
> Problem
> =======
> 
> The Rust wrapper for object_ref() is marked unsafe and has:
> > The object must not be embedded in another unless the outer
> > object is guaranteed to have a longer lifetime.
> 
> In other words, object_ref() does not work for embedded objects and
> does not keep embedded objects alive. MemoryRegion has its own
> memory_region_ref() helper to call object_ref() on its owner for this
> reason.
> 
> However, this is insufficient to avoid calling object_ref() for all
> embedded objects. For example, consider an embedded Device that has a
> MemoryRegion. When referencing a MemoryRegion for guest memory access,
> QEMU automatically references the owning Device to keep the MemoryRegion
> alive. However, that reference is ineffective if the Device itself is
> embedded, because object_ref() does not keep the containing storage
> alive.

Do we know how many examples we have of embedding objects inside
another ?

I would much prefer if we forbid the embedding of objects. It is
horrible design practice to have some QOM objects which can be
freed via reference count and some which cannot.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|



  reply	other threads:[~2026-06-15  8:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-15  4:11 [PATCH 0/2] qom: Tighten object lifetime handling Akihiko Odaki
2026-06-15  4:11 ` [PATCH 1/2] qom: Reject temporary object resurrection Akihiko Odaki
2026-06-15  8:14   ` Daniel P. Berrangé
2026-06-15  8:34   ` Kevin Wolf
2026-06-15  8:50     ` Akihiko Odaki
2026-06-15  4:11 ` [PATCH 2/2] qom: Manage references to embedded child objects Akihiko Odaki
2026-06-15  8:12   ` Daniel P. Berrangé [this message]
2026-06-15  8:31     ` Peter Maydell
2026-06-15  8:34       ` Daniel P. Berrangé
2026-06-15  9:28         ` Peter Maydell
2026-06-15 13:42           ` Mark Cave-Ayland
2026-06-15 13:55             ` Akihiko Odaki
2026-06-15 14:01             ` Daniel P. Berrangé
2026-06-15 20:09             ` BALATON Zoltan
2026-06-15 13:29     ` Mark Cave-Ayland
2026-06-15 10:59   ` Daniel P. Berrangé
2026-06-15 12:02     ` 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=ai-z14dMCK33_pis@redhat.com \
    --to=berrange@redhat.com \
    --cc=berto@igalia.com \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=manos.pitsidianakis@linaro.org \
    --cc=odaki@rsg.ci.i.u-tokyo.ac.jp \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@mailo.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-rust@nongnu.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.