All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Price <steven.price@arm.com>
To: lihongtao <lihongtao@kylinos.cn>,
	Boris Brezillon <boris.brezillon@collabora.com>
Cc: Rob Herring <robh@kernel.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/panfrost: Fix leak when free gem object
Date: Thu, 17 Jul 2025 11:23:24 +0100	[thread overview]
Message-ID: <97149cf3-b3cb-4b90-a486-7eea5ee41b59@arm.com> (raw)
In-Reply-To: <20250710030527.167710-1-lihongtao@kylinos.cn>

On 10/07/2025 04:05, lihongtao wrote:
> obj->mappings.lock should be destroyed when free
> panfrost gem object in panfrost_gem_free_object.

mutex_destroy() doesn't actually release any resources. It is purely a
debugging feature (if CONFIG_DEBUG_MUTEXES is disabled then it is
compiled away completely).

So it's not a "leak" as such. But there is some value in using it as it
would (in debug builds) warn us if we attempt to destroy a locked mutex
or attempt to use a mutex after the destroy.

But if we're going to fix this I think we should be more complete. A
quick grep should we have 6 different mutexes in panfrost:

panfrost_device.c:      mutex_init(&pfdev->sched_lock);
panfrost_device.c:      mutex_init(&pfdev->debugfs.gems_lock);
panfrost_drv.c: mutex_init(&pfdev->shrinker_lock);
panfrost_gem.c: mutex_init(&obj->mappings.lock);
panfrost_gem.c: mutex_init(&obj->label.lock);
panfrost_perfcnt.c:     mutex_init(&perfcnt->lock);

But there's only one existing call to mutex_destroy():

panfrost_gem.c: mutex_destroy(&bo->label.lock);

It would be good to consider if the other mutexes should also be destroyed.

Thanks,
Steve

> 
> Signed-off-by: lihongtao <lihongtao@kylinos.cn>
> ---
>  drivers/gpu/drm/panfrost/panfrost_gem.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c b/drivers/gpu/drm/panfrost/panfrost_gem.c
> index 963f04ba2de6..00549f482eec 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> @@ -49,6 +49,7 @@ static void panfrost_gem_free_object(struct drm_gem_object *obj)
>  		kvfree(bo->sgts);
>  	}
>  
> +	mutex_destroy(&bo->mappings.lock);
>  	drm_gem_shmem_free(&bo->base);
>  }
>  


  reply	other threads:[~2025-07-17 10:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-10  3:05 [PATCH] drm/panfrost: Fix leak when free gem object lihongtao
2025-07-17 10:23 ` Steven Price [this message]
2025-07-17 10:50 ` Markus Elfring

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=97149cf3-b3cb-4b90-a486-7eea5ee41b59@arm.com \
    --to=steven.price@arm.com \
    --cc=airlied@gmail.com \
    --cc=boris.brezillon@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=lihongtao@kylinos.cn \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=robh@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    /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.