Re: [PATCH v8 03/16] drm/panfrost: Move debugfs initialisation to relevant subsystems

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Use-after-free of BO label string in debugfs due to incorrect cleanup ordering
--

commit a176b75fb18c68d91dd9610fff6763a62e825a4f
Author: Adrián Larumbe <adrian.larumbe@collabora.com>

drm/panfrost: Move debugfs initialisation to relevant subsystems

This commit moves the initialization of debugfs knobs out of panfrost_drv.c
and into the specific subsystems they provide information about, such as gem
and sched.

> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c b/drivers/gpu/drm/panfrost/panfrost_gem.c
> index 383ac8cd56456..518f24549b9de 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c

[ ... ]

> @@ -756,4 +757,28 @@ void panfrost_gem_debugfs_print_bos(struct panfrost_device *pfdev,
>  	seq_printf(m, "Total size: %zd, Total resident: %zd, Total reclaimable: %zd\n",
>  		   totals.size, totals.resident, totals.reclaimable);
>  }
> +
> +static int panfrost_gems_show(struct seq_file *m, void *data)
> +{
> +	struct drm_info_node *node = m->private;
> +	struct panfrost_device *pfdev = to_panfrost_device(node->minor->dev);
> +
> +	panfrost_gem_debugfs_print_bos(pfdev, m);

[Severity: High]
This is a pre-existing issue, but does this debugfs read path have a race
condition with BO destruction that could lead to a use-after-free?

When reading the gems debugfs file, panfrost_gem_debugfs_print_bos() holds
the gems_lock and iterates over BOs. If it reads a positive refcount for a
BO, and immediately after that the last reference to the BO is dropped by
another thread, panfrost_gem_free_object() in
drivers/gpu/drm/panfrost/panfrost_gem.c is called.

In panfrost_gem_free_object(), the cleanup order frees the label string
before removing the BO from the debugfs list:

panfrost_gem_free_object()
   ...
   kfree_const(bo->label.str);
   panfrost_gem_debugfs_bo_rm(bo);
   mutex_destroy(&bo->label.lock);

Because the string is freed before the BO is removed from the debugfs list
and before synchronization on the list lock occurs in
panfrost_gem_debugfs_bo_rm(), the debugfs printing thread could dereference
the freed bo->label.str.

Should panfrost_gem_debugfs_bo_rm(bo) be called before freeing the string
and destroying the lock to prevent this?

> +
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260907-claude-fixes-v8-0-c2bcb5e82184@collabora.com?part=3