From: "Michael S. Tsirkin" <mst@redhat.com>
To: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Yanan Wang" <wangyanan55@huawei.com>,
"John Snow" <jsnow@redhat.com>,
"BALATON Zoltan" <balaton@eik.bme.hu>,
"Jiaxun Yang" <jiaxun.yang@flygoat.com>,
"Nicholas Piggin" <npiggin@gmail.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>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"David Hildenbrand" <david@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Laurent Vivier" <lvivier@redhat.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org,
qemu-ppc@nongnu.org
Subject: Re: [PATCH] docs/devel: Prohibit calling object_unparent() for memory region
Date: Tue, 10 Sep 2024 13:26:49 -0400 [thread overview]
Message-ID: <20240910132635-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20240829-memory-v1-1-ac07af2f4fa5@daynix.com>
On Thu, Aug 29, 2024 at 02:46:48PM +0900, Akihiko Odaki wrote:
> Previously it was allowed to call object_unparent() for a memory region
> in instance_finalize() of its parent. However, such a call typically
> has no effect because child objects get unparented before
> instance_finalize().
>
> Worse, memory regions typically gets finalized when they get unparented
> before instance_finalize(). This means calling object_unparent() for
> them in instance_finalize() is to call the function for an object
> already finalized, which should be avoided.
>
> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
who's applying this? Paolo?
> ---
> docs/devel/memory.rst | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/docs/devel/memory.rst b/docs/devel/memory.rst
> index 69c5e3f914ac..83760279e3db 100644
> --- a/docs/devel/memory.rst
> +++ b/docs/devel/memory.rst
> @@ -168,11 +168,10 @@ and VFIOQuirk in hw/vfio/pci.c.
>
> You must not destroy a memory region as long as it may be in use by a
> device or CPU. In order to do this, as a general rule do not create or
> -destroy memory regions dynamically during a device's lifetime, and only
> -call object_unparent() in the memory region owner's instance_finalize
> -callback. The dynamically allocated data structure that contains the
> -memory region then should obviously be freed in the instance_finalize
> -callback as well.
> +destroy memory regions dynamically during a device's lifetime, and do not
> +call object_unparent(). The dynamically allocated data structure that contains
> +the memory region then should be freed in the instance_finalize callback, which
> +is called after it gets unparented.
>
> If you break this rule, the following situation can happen:
>
> @@ -199,8 +198,9 @@ but nevertheless it is used in a few places.
>
> For regions that "have no owner" (NULL is passed at creation time), the
> machine object is actually used as the owner. Since instance_finalize is
> -never called for the machine object, you must never call object_unparent
> -on regions that have no owner, unless they are aliases or containers.
> +never called for the machine object, you must never free regions that have no
> +owner, unless they are aliases or containers, which you can manually call
> +object_unparent() for.
>
>
> Overlapping regions and priority
>
> ---
> base-commit: 31669121a01a14732f57c49400bc239cf9fd505f
> change-id: 20240829-memory-cfd3ee0af44d
>
> Best regards,
> --
> Akihiko Odaki <akihiko.odaki@daynix.com>
next prev parent reply other threads:[~2024-09-10 17:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-29 5:46 [PATCH] docs/devel: Prohibit calling object_unparent() for memory region Akihiko Odaki
2024-09-10 17:26 ` Michael S. Tsirkin [this message]
2024-09-10 18:21 ` Peter Maydell
2024-10-08 13:33 ` Peter Maydell
2024-10-12 8:07 ` 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=20240910132635-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=aik@ozlabs.ru \
--cc=akihiko.odaki@daynix.com \
--cc=alex.bennee@linaro.org \
--cc=balaton@eik.bme.hu \
--cc=danielhb413@gmail.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=eduardo@habkost.net \
--cc=farosas@suse.de \
--cc=harshpb@linux.ibm.com \
--cc=jiaxun.yang@flygoat.com \
--cc=jsnow@redhat.com \
--cc=lvivier@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=npiggin@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=thuth@redhat.com \
--cc=wangyanan55@huawei.com \
/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.