qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Akihiko Odaki <akihiko.odaki@daynix.com>
To: "Xenia Ragiadakou" <xenia.ragiadakou@amd.com>,
	"Huang Rui" <ray.huang@amd.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Anthony PERARD" <anthony.perard@citrix.com>,
	"Antonio Caggiano" <quic_acaggian@quicinc.com>,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
	"Robert Beckett" <bob.beckett@collabora.com>,
	"Dmitry Osipenko" <dmitry.osipenko@collabora.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	qemu-devel@nongnu.org
Cc: xen-devel@lists.xenproject.org,
	"Gurchetan Singh" <gurchetansingh@chromium.org>,
	"Albert Esteve" <aesteve@redhat.com>,
	ernunes@redhat.com, "Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Alyssa Ross" <hi@alyssa.is>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Pierre-Eric Pelloux-Prayer" <pierre-eric.pelloux-prayer@amd.com>,
	"Honglei Huang" <honglei1.huang@amd.com>,
	"Julia Zhang" <julia.zhang@amd.com>,
	"Chen Jiqian" <Jiqian.Chen@amd.com>
Subject: Re: [QEMU PATCH v5 07/13] softmmu/memory: enable automatic deallocation of memory regions
Date: Wed, 20 Sep 2023 07:18:24 +0900	[thread overview]
Message-ID: <73a35fbb-c9a4-41dc-a6c7-26037b0e412f@daynix.com> (raw)
In-Reply-To: <32a68715-201b-9923-9600-fe5ae49e4b7b@amd.com>

On 2023/09/19 23:21, Xenia Ragiadakou wrote:
> 
> On 19/9/23 13:44, Akihiko Odaki wrote:
>> On 2023/09/19 19:28, Xenia Ragiadakou wrote:
>>>
>>> On 15/9/23 18:11, Akihiko Odaki wrote:
>>>> On 2023/09/15 20:11, Huang Rui wrote:
>>>>> From: Xenia Ragiadakou <xenia.ragiadakou@amd.com>
>>>>>
>>>>> When the memory region has a different life-cycle from that of her 
>>>>> parent,
>>>>> could be automatically released, once has been unparent and once 
>>>>> all of her
>>>>> references have gone away, via the object's free callback.
>>>>>
>>>>> However, currently, references to the memory region are held by its 
>>>>> owner
>>>>> without first incrementing the memory region object's reference count.
>>>>> As a result, the automatic deallocation of the object, not taking into
>>>>> account those references, results in use-after-free memory corruption.
>>>>>
>>>>> This patch increases the reference count of an owned memory region 
>>>>> object
>>>>> on each memory_region_ref() and decreases it on each 
>>>>> memory_region_unref().
>>>>>
>>>>> Signed-off-by: Xenia Ragiadakou <xenia.ragiadakou@amd.com>
>>>>> Signed-off-by: Huang Rui <ray.huang@amd.com>
>>>>> ---
>>>>>
>>>>> V4 -> V5:
>>>>>      - ref/unref only owned memory regions (Akihiko)
>>>>>
>>>>>   softmmu/memory.c | 5 +++++
>>>>>   1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/softmmu/memory.c b/softmmu/memory.c
>>>>> index 7d9494ce70..15e1699750 100644
>>>>> --- a/softmmu/memory.c
>>>>> +++ b/softmmu/memory.c
>>>>> @@ -1800,6 +1800,9 @@ void memory_region_ref(MemoryRegion *mr)
>>>>>       /* MMIO callbacks most likely will access data that belongs
>>>>>        * to the owner, hence the need to ref/unref the owner whenever
>>>>>        * the memory region is in use.
>>>>> +     * Likewise, the owner keeps references to the memory region,
>>>>> +     * hence the need to ref/unref the memory region object to 
>>>>> prevent
>>>>> +     * its automatic deallocation while still referenced by its 
>>>>> owner.
>>>>
>>>> This comment does not make sense. Traditionally no such automatic 
>>>> deallocation happens so the owner has been always required to free 
>>>> the memory region when it gets finalized.
>>>>
>>>> "[QEMU PATCH v5 09/13] virtio-gpu: Handle resource blob commands" 
>>>> introduces a different kind of memory region, which can be freed 
>>>> anytime before the device gets finalized. Even in this case, the 
>>>> owner removes the reference to the memory owner by doing res->region 
>>>> = NULL;
>>>
>>> Hi Akihiko,
>>>
>>> You are right, the word "owner" is not correct. The issue observed 
>>> was due to the references kept in flatview ranges and the fact that 
>>> flatview_destroy() is asynchronous and was called after memory 
>>> region's destruction.
>>>
>>> If I replace the word "owner" with "memory subsystem" in the commit 
>>> message and drop the comment, would that be ok with you? or do want 
>>> to suggest something else?
>>
>> This will extend the lifetime of the memory region, but the underlying 
>> memory is still synchronously freed. Can you show that the flatview 
>> range will not be used to read the freed memory?
> 
> Yes, the intention of this patch is to delay the mr object finalization 
> until all memory_region_unref() on this mr have been taken place.
> 
> What do you mean by "the underlying memory is still synchronously freed"?
> 

A pointer is passed to memory_region_init_ram_ptr() with the ptr 
parameter when initializing the memory region and the memory region 
keeps the pointer.

In virtio_gpu_virgl_resource_unmap(), the memory pointed with the 
pointer is unmapped with virgl_renderer_resource_unmap() and makes the 
pointer kept by the memory region dangling though the lifetime of the 
memory region is extended with this patch. Can you show that the 
dangling pointer the memory region has will never be referenced?


  reply	other threads:[~2023-09-19 22:19 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-15 11:11 [QEMU PATCH v5 00/13] Support blob memory and venus on qemu Huang Rui
2023-09-15 11:11 ` [QEMU PATCH v5 01/13] virtio: Add shared memory capability Huang Rui
2023-09-15 11:11 ` [QEMU PATCH v5 02/13] virtio-gpu: CONTEXT_INIT feature Huang Rui
2023-09-15 11:11 ` [QEMU PATCH v5 03/13] virtio-gpu: hostmem Huang Rui
2023-09-15 11:11 ` [QEMU PATCH v5 04/13] virtio-gpu: blob prep Huang Rui
2023-09-15 11:11 ` [QEMU PATCH v5 05/13] virtio-gpu: Configure context init for virglrenderer Huang Rui
2023-09-19  8:17   ` Marc-André Lureau
2023-09-20  8:04     ` Huang Rui
2023-10-10 11:41   ` Dmitry Osipenko
2023-10-10 11:51     ` Daniel P. Berrangé
2023-10-17 17:46       ` Dmitry Osipenko
2023-09-15 11:11 ` [QEMU PATCH v5 06/13] virtio-gpu: Support context init feature with virglrenderer Huang Rui
2023-09-15 15:20   ` Akihiko Odaki
2023-09-16 10:32     ` Huang Rui
2023-09-16 10:42       ` Akihiko Odaki
2023-09-17  5:45         ` Huang Rui
2023-09-17  5:49           ` Akihiko Odaki
2023-09-18  5:43             ` Huang Rui
2023-09-18  6:07               ` Akihiko Odaki
2023-09-18  6:20                 ` Huang Rui
2023-09-18  6:22                   ` Akihiko Odaki
2023-09-15 16:58   ` Akihiko Odaki
2023-09-16 10:36     ` Huang Rui
2023-09-15 11:11 ` [QEMU PATCH v5 07/13] softmmu/memory: enable automatic deallocation of memory regions Huang Rui
2023-09-15 15:11   ` Akihiko Odaki
2023-09-19 10:28     ` Xenia Ragiadakou
2023-09-19 10:44       ` Akihiko Odaki
2023-09-19 14:21         ` Xenia Ragiadakou
2023-09-19 22:18           ` Akihiko Odaki [this message]
2023-09-20  8:57             ` Xenia Ragiadakou
2023-09-20 10:18               ` Akihiko Odaki
2023-09-15 11:11 ` [QEMU PATCH v5 08/13] virtio-gpu: Don't require udmabuf when blobs and virgl are enabled Huang Rui
2023-09-15 11:11 ` [QEMU PATCH v5 09/13] virtio-gpu: Handle resource blob commands Huang Rui
2023-09-15 16:04   ` Akihiko Odaki
2023-09-15 16:37     ` Akihiko Odaki
2023-09-20  5:50       ` Huang Rui via
2023-09-20  5:54         ` Akihiko Odaki
2023-09-20  6:11           ` Huang Rui via
2023-09-18  8:36     ` Huang Rui
2023-09-18  8:39       ` Akihiko Odaki
2023-09-19  8:44   ` Marc-André Lureau
2023-09-20  8:41     ` Huang Rui
2023-09-15 11:11 ` [QEMU PATCH v5 10/13] virtio-gpu: Resource UUID Huang Rui
2023-09-15 16:48   ` Akihiko Odaki
2023-09-20  7:55     ` Huang Rui
2023-09-19  9:00   ` Marc-André Lureau
2023-09-20 10:00     ` Huang Rui
2023-09-15 11:11 ` [QEMU PATCH v5 11/13] virtio-gpu: Support Venus capset Huang Rui
2023-09-19  9:02   ` Marc-André Lureau
2023-09-20 10:06     ` Huang Rui
2023-09-15 11:11 ` [QEMU PATCH v5 12/13] virtio-gpu: Initialize Venus Huang Rui
2023-10-10 12:10   ` Dmitry Osipenko
2023-09-15 11:11 ` [QEMU PATCH v5 13/13] virtio-gpu: Enable virglrenderer render server flag for venus Huang Rui
2023-10-10 11:48   ` Dmitry Osipenko
2023-10-10 11:57 ` [QEMU PATCH v5 00/13] Support blob memory and venus on qemu Dmitry Osipenko

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=73a35fbb-c9a4-41dc-a6c7-26037b0e412f@daynix.com \
    --to=akihiko.odaki@daynix.com \
    --cc=Jiqian.Chen@amd.com \
    --cc=aesteve@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=alexander.deucher@amd.com \
    --cc=anthony.perard@citrix.com \
    --cc=bob.beckett@collabora.com \
    --cc=christian.koenig@amd.com \
    --cc=dgilbert@redhat.com \
    --cc=dmitry.osipenko@collabora.com \
    --cc=ernunes@redhat.com \
    --cc=gurchetansingh@chromium.org \
    --cc=hi@alyssa.is \
    --cc=honglei1.huang@amd.com \
    --cc=julia.zhang@amd.com \
    --cc=kraxel@redhat.com \
    --cc=mst@redhat.com \
    --cc=philmd@linaro.org \
    --cc=pierre-eric.pelloux-prayer@amd.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quic_acaggian@quicinc.com \
    --cc=ray.huang@amd.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xenia.ragiadakou@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).