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