From: Steven Price <steven.price@arm.com>
To: "Daniel Stone" <daniel@fooishbar.org>,
"Adrián Larumbe" <adrian.larumbe@collabora.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Boris Brezillon" <boris.brezillon@collabora.com>,
kernel@collabora.com, "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>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>,
"Linux Media Mailing List" <linux-media@vger.kernel.org>,
"moderated list:DMA BUFFER SHARING FRAMEWORK"
<linaro-mm-sig@lists.linaro.org>
Subject: Re: [PATCH v2 3/3] drm/panfrost: show device-wide list of DRM GEM objects over DebugFS
Date: Mon, 19 May 2025 17:02:10 +0100 [thread overview]
Message-ID: <6a00017f-89dd-47b9-a4db-ceedd63f456f@arm.com> (raw)
In-Reply-To: <CAPj87rOiEa1bTOPqyauYhoVoXEtNeDjE+DkLbzeGVJ1tW9fJcQ@mail.gmail.com>
On 15/05/2025 19:04, Daniel Stone wrote:
> Hi Steven,
>
> On Thu, 8 May 2025 at 11:42, Steven Price <steven.price@arm.com> wrote:
>> I'm also seeing a splat when running this, see below. I haven't got my
>> head around how this is happening, but I see it when glmark quits at the
>> end of the test.
>>
>> [ 399.505066] Unable to handle kernel NULL pointer dereference at virtual address 00000004 when write
>> [...]
>> [ 399.882216] Call trace:
>> [ 399.882222] panfrost_gem_free_object [panfrost] from drm_gem_handle_delete+0x84/0xb0
>> [ 399.893813] drm_gem_handle_delete from drm_ioctl+0x2b8/0x4f4
>> [ 399.900237] drm_ioctl from sys_ioctl+0x428/0xe30
>> [ 399.905496] sys_ioctl from ret_fast_syscall+0x0/0x1c
>
> Soooo. Let's assume it has to actually occur in
> panfrost_gem_debugfs_bo_rm(), since that's all that's changed here.
>
> I don't think pfdev can be NULL here, because we've already
> dereferenced ptdev and written to a structure member earlier in
> panfrost_gem_free_object(). I don't think it can be the debugfs mutex,
> because a) that's initialised with the device, and b) wouldn't be
> offset 0x4.
>
> I'm looking then at list_del_init(&bo->debugfs.node), which would
> effectively execute bo->debugfs.node->next->prev =
> bo->debugfs.node->prev. So if bo->debugfs.node->next was NULL, that
> would explain a write to 0x4 on 32-bit systems.
So I finally got some time to do some debugging on this. And you are
absolutely correct on where the fault is triggered.
The cause of it is that panfrost_gem_debugfs_bo_add() is called from
panfrost_gem_create(), but that isn't the only place that Panfrost GEM
objects are created - it turns out panfrost_perfcnt_enable_locked() also
calls drm_gem_shmem_create(). And in that case the list next/prev
pointers are left set to NULL, causing things to blow up when the GEM
object is freed.
The below patch gets things working, or alternatively just init the list
in panfrost_gem_create_object() if we don't want to include the perfcnt
buffer in the list.
Steve
---8<--
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index fe2cdbe8baf0..51da13cd81f0 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -297,13 +297,14 @@ struct drm_gem_object
*panfrost_gem_create_object(struct drm_device *dev, size_t
obj->base.map_wc = !pfdev->coherent;
mutex_init(&obj->label.lock);
+ panfrost_gem_debugfs_bo_add(pfdev, obj);
+
return &obj->base.base;
}
struct panfrost_gem_object *
panfrost_gem_create(struct drm_device *dev, size_t size, u32 flags)
{
- struct panfrost_device *pfdev = dev->dev_private;
struct drm_gem_shmem_object *shmem;
struct panfrost_gem_object *bo;
@@ -319,8 +320,6 @@ panfrost_gem_create(struct drm_device *dev, size_t
size, u32 flags)
bo->noexec = !!(flags & PANFROST_BO_NOEXEC);
bo->is_heap = !!(flags & PANFROST_BO_HEAP);
- panfrost_gem_debugfs_bo_add(pfdev, bo);
-
return bo;
}
next prev parent reply other threads:[~2025-05-19 16:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-07 16:07 [PATCH v2 0/3] Panfrost BO tagging and GEMS debug display Adrián Larumbe
2025-05-07 16:07 ` [PATCH v2 1/3] drm/panfrost: Add BO labelling to Panfrost Adrián Larumbe
2025-05-07 16:07 ` [PATCH v2 2/3] drm/panfrost: Add driver IOCTL for setting BO labels Adrián Larumbe
2025-05-07 16:07 ` [PATCH v2 3/3] drm/panfrost: show device-wide list of DRM GEM objects over DebugFS Adrián Larumbe
2025-05-08 10:42 ` Steven Price
2025-05-15 18:04 ` Daniel Stone
2025-05-19 16:02 ` Steven Price [this message]
2025-05-20 12:53 ` Adrián Larumbe
2025-05-20 11:30 ` Adrián Larumbe
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=6a00017f-89dd-47b9-a4db-ceedd63f456f@arm.com \
--to=steven.price@arm.com \
--cc=adrian.larumbe@collabora.com \
--cc=airlied@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=christian.koenig@amd.com \
--cc=daniel@fooishbar.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kernel@collabora.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=robh@kernel.org \
--cc=simona@ffwll.ch \
--cc=sumit.semwal@linaro.org \
--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 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).