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.
What I _can't_ see is how that would be. Even a double-free calls list_del_init() so we're all good. If the shmem alloc failed then this would splat because panfrost_gem_debugfs_bo_add() happens too late, and we end up with an uninitialised list head - so that's one to fix. But I assume that isn't what happens here. I wonder if it's the import path, and the panfrost_gem_debugfs_bo_add() call instead needs to be in the panfrost_gem_create_object() callback rather than only panfrost_gem_create() which is called through the ioctl?
Cheers, Daniel