From: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
To: Gurchetan Singh <gurchetansingh@chromium.org>
Cc: qemu-devel@nongnu.org,
"Marc-André Lureau" <marcandre.lureau@gmail.com>,
"Philippe Mathieu-Daudé " <philmd@linaro.org>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Alyssa Ross" <hi@alyssa.is>
Subject: Re: [PATCH v2 3/3] virtio-gpu-rutabaga.c: override resource_destroy method
Date: Tue, 30 Jan 2024 08:53:58 +0200 [thread overview]
Message-ID: <82bb2.rl2cr4qt6406@linaro.org> (raw)
In-Reply-To: <CAAfnVBk1jsOxvOd0k2otPOEz65v5ngN4E98LMHhTr5Vtc2fOcQ@mail.gmail.com>
On Tue, 30 Jan 2024 03:26, Gurchetan Singh <gurchetansingh@chromium.org> wrote:
>On Mon, Jan 29, 2024 at 7:46 AM Manos Pitsidianakis <
>manos.pitsidianakis@linaro.org> wrote:
>
>> When the Rutabaga GPU device frees resources, it calls
>> rutabaga_resource_unref for that resource_id. However, when the generic
>> VirtIOGPU functions destroys resources, it only removes the
>> virtio_gpu_simple_resource from the device's VirtIOGPU->reslist list.
>> The rutabaga resource associated with that resource_id is then leaked.
>>
>> This commit overrides the resource_destroy class method introduced in
>> the previous commit to fix this.
>>
>> Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
>> ---
>> hw/display/virtio-gpu-rutabaga.c | 51 ++++++++++++++++++++++++--------
>> 1 file changed, 39 insertions(+), 12 deletions(-)
>>
>> diff --git a/hw/display/virtio-gpu-rutabaga.c
>> b/hw/display/virtio-gpu-rutabaga.c
>> index 9e67f9bd51..6ac0776005 100644
>> --- a/hw/display/virtio-gpu-rutabaga.c
>> +++ b/hw/display/virtio-gpu-rutabaga.c
>> @@ -148,14 +148,42 @@ rutabaga_cmd_create_resource_3d(VirtIOGPU *g,
>> }
>>
>> static void
>> +virtio_gpu_rutabaga_resource_unref(VirtIOGPU *g,
>> + struct virtio_gpu_simple_resource *res,
>> + Error **errp)
>> +{
>> + int32_t result;
>> + const char *strerror = NULL;
>> + VirtIOGPURutabaga *vr = VIRTIO_GPU_RUTABAGA(g);
>> +
>> + result = rutabaga_resource_unref(vr->rutabaga, res->resource_id);
>> + if (result) {
>> + error_setg(errp, "%s: rutabaga_resource_unref returned %"PRIi32
>> + " for resource_id = %"PRIu32, __func__, result,
>> + res->resource_id);
>> + strerror = strerrorname_np((int)result);
>> + if (strerror != NULL) {
>> + error_append_hint(errp, "%s: %s\n",
>> + strerror, strerrordesc_np((int)result) ? :
>> "");
>> + }
>>
>
>Can't we rely on virtio_gpu_rutabaga_debug_cb(..) to report an error when
>the resource ID is not found?
IIUC that callback is called from the external library, and uses its own
type (const struct rutabaga *debug) which is not how the interface works
here. rutabaga_resource_unref() returns an int32_t. Besides this isn't a
debug print but an error print.
>
>> + }
>> +
>> + if (res->image) {
>> + pixman_image_unref(res->image);
>> + }
>> +
>> + QTAILQ_REMOVE(&g->reslist, res, next);
>> + g_free(res);
>> +}
>> +
>> +static void
>> rutabaga_cmd_resource_unref(VirtIOGPU *g,
>> struct virtio_gpu_ctrl_command *cmd)
>> {
>> - int32_t result;
>> + int32_t result = 0;
>> struct virtio_gpu_simple_resource *res;
>> struct virtio_gpu_resource_unref unref;
>> -
>> - VirtIOGPURutabaga *vr = VIRTIO_GPU_RUTABAGA(g);
>> + Error *local_err = NULL;
>>
>> VIRTIO_GPU_FILL_CMD(unref);
>>
>> @@ -164,15 +192,14 @@ rutabaga_cmd_resource_unref(VirtIOGPU *g,
>> res = virtio_gpu_find_resource(g, unref.resource_id);
>> CHECK(res, cmd);
>>
>> - result = rutabaga_resource_unref(vr->rutabaga, unref.resource_id);
>> - CHECK(!result, cmd);
>> -
>> - if (res->image) {
>> - pixman_image_unref(res->image);
>> + virtio_gpu_rutabaga_resource_unref(g, res, &local_err);
>> + if (local_err) {
>> + error_report_err(local_err);
>> + /* local_err was freed, do not reuse it. */
>> + local_err = NULL;
>> + result = 1;
>> }
>> -
>> - QTAILQ_REMOVE(&g->reslist, res, next);
>> - g_free(res);
>> + CHECK(!result, cmd);
>> }
>>
>> static void
>> @@ -1099,7 +1126,7 @@ static void
>> virtio_gpu_rutabaga_class_init(ObjectClass *klass, void *data)
>> vgc->handle_ctrl = virtio_gpu_rutabaga_handle_ctrl;
>> vgc->process_cmd = virtio_gpu_rutabaga_process_cmd;
>> vgc->update_cursor_data = virtio_gpu_rutabaga_update_cursor;
>> -
>> + vgc->resource_destroy = virtio_gpu_rutabaga_resource_unref;
>> vdc->realize = virtio_gpu_rutabaga_realize;
>> device_class_set_props(dc, virtio_gpu_rutabaga_properties);
>> }
>> --
>> γαῖα πυρί μιχθήτω
>>
>>
next prev parent reply other threads:[~2024-01-30 6:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-29 15:45 [PATCH v2 0/3] Fix resource freeing bugs in virtio-gpu-rutabaga Manos Pitsidianakis
2024-01-29 15:45 ` [PATCH v2 1/3] hw/display/virtio-gpu.c: use reset_bh class method Manos Pitsidianakis
2024-01-29 15:45 ` [PATCH v2 2/3] virtio-gpu.c: add resource_destroy " Manos Pitsidianakis
2024-01-30 12:46 ` Marc-André Lureau
2024-01-29 15:45 ` [PATCH v2 3/3] virtio-gpu-rutabaga.c: override resource_destroy method Manos Pitsidianakis
2024-01-30 1:26 ` Gurchetan Singh
2024-01-30 6:53 ` Manos Pitsidianakis [this message]
2024-01-30 12:50 ` Marc-André Lureau
2024-01-30 13:01 ` Manos Pitsidianakis
2024-01-30 13:09 ` Marc-André Lureau
2024-01-30 13:50 ` Manos Pitsidianakis
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=82bb2.rl2cr4qt6406@linaro.org \
--to=manos.pitsidianakis@linaro.org \
--cc=gurchetansingh@chromium.org \
--cc=hi@alyssa.is \
--cc=kraxel@redhat.com \
--cc=marcandre.lureau@gmail.com \
--cc=mst@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@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 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).