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 <[email protected]> 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/[email protected]?part=2
