Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm/panfrost: UAF in reset work due to incorrect teardown order --
commit cfa26c5946307af48b39c322e0d8f2fd03c46e05 Author: Adrián Larumbe <[email protected]> drm/panfrost: Add debugfs knob for manually triggering a GPU reset This patch adds a debugfs knob to manually trigger a GPU reset for testing purposes. It also updates the teardown path to disable rather than cancel the reset work to prevent the knob from triggering resets during device removal. > diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c > b/drivers/gpu/drm/panfrost/panfrost_job.c > index 00fb36c577df7..ab65786bf63bc 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_job.c > +++ b/drivers/gpu/drm/panfrost/panfrost_job.c > @@ -932,7 +932,7 @@ void panfrost_jm_fini(struct panfrost_device *pfdev) > drm_sched_fini(&js->queue[j].sched); > } > > - cancel_work_sync(&pfdev->reset.work); > + disable_work_sync(&pfdev->reset.work); [Severity: High] Does this teardown order leave a window for a use-after-free if a reset is triggered during unbinding? In panfrost_jm_fini(), the DRM schedulers are destroyed via drm_sched_fini() before the asynchronous reset work is disabled. The drm_sched_fini() function tears down the scheduler, destroying sched->submit_wq and freeing sched->sched_rq. If a GPU reset is scheduled right before or during driver unbinding (for example, by writing to the newly introduced debugfs reset knob), the reset work can run asynchronously while panfrost_jm_fini() executes. The reset work calls drm_sched_stop() and drm_sched_start(), which ultimately queues work onto the scheduler's now-destroyed submit_wq, leading to a crash. Should disable_work_sync() be called before the loop that destroys the DRM schedulers? -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=10
