Re: [RFC v3 2/2] drm/panthor: Create per queue priority workqueues

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Asynchronous teardown of `panthor_group` via `panthor_cleanup_wq` can race with device unplug and `drm_dev_release`, causing a Use-After-Free of the DRM device and workqueues.
--

--- Patch [2]: [RFC v3 2/2] drm/panthor: Create per queue priority workqueues ---
commit 55f41e3219b2c06b949efdf0212b58b264d95a7b
Author: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>

drm/panthor: Create per queue priority workqueues

This commit splits the single workqueue used by the DRM scheduler into
multiple priority-based workqueues (low, medium, high, rt) to better serve
different GPU priority levels.

> diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c
> index 5832dccfc0932..70e84ebb6c663 100644
> --- a/drivers/gpu/drm/panthor/panthor_sched.c
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c

[ ... ]

> @@ -4084,6 +4096,15 @@ static void panthor_sched_fini(struct drm_device *ddev, void *res)
>  	if (!sched || !sched->csg_slot_count)
>  		return;
>  
> +	if (sched->submit_wq[PANTHOR_CSG_PRIORITY_MEDIUM])
> +		destroy_workqueue(sched->submit_wq[PANTHOR_CSG_PRIORITY_MEDIUM]);
> +
> +	if (sched->submit_wq[PANTHOR_CSG_PRIORITY_HIGH])
> +		destroy_workqueue(sched->submit_wq[PANTHOR_CSG_PRIORITY_HIGH]);
> +
> +	if (sched->submit_wq[PANTHOR_CSG_PRIORITY_RT])
> +		destroy_workqueue(sched->submit_wq[PANTHOR_CSG_PRIORITY_RT]);
> +

[Severity: High]
This is a pre-existing issue, but can this synchronous destruction race
with the asynchronous teardown of the queue?

When a user closes the device, the driver can schedule group_release on
the global panthor_cleanup_wq without holding a reference to the DRM
device:

group_release()
    ...
    queue_work(panthor_cleanup_wq, &group->release_work);

If this was the last reference, drm_dev_release can run immediately and
call panthor_sched_fini, which destroys these new submit_wq workqueues
and frees the ptdev allocation. 

Meanwhile, the asynchronous release work executing group_free_queue can
attempt to access the destroyed queue->scheduler.submit_wq, or access
the already-freed ptdev memory:

panthor_kernel_bo_destroy()
    ...
    ptdev = container_of(bo->obj->dev, struct panthor_device, base);

Could this lead to a use-after-free since the release work isn't flushed
before the device teardown?

>  	if (sched->wq)
>  		destroy_workqueue(sched->wq);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260717090209.26931-1-tvrtko.ursulin@igalia.com?part=2