Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm/lima: unhandled interrupt storm during device teardown --
commit 8abd934c293282a7fc2e36fd5ffb16c36332e554 Author: Fan Wu <[email protected]> drm/lima: fix use-after-free of recover work on device removal This commit fixes a use-after-free issue on device removal by draining the recover_work while the task slab and scheduler are still alive. It frees the GP and GP MMU interrupts before the GP pipe teardown and stops the GP after the scheduler is finished. > diff --git a/drivers/gpu/drm/lima/lima_device.c > b/drivers/gpu/drm/lima/lima_device.c > index 7c873e62c16da..e4dbd8baf33c6 100644 > --- a/drivers/gpu/drm/lima/lima_device.c > +++ b/drivers/gpu/drm/lima/lima_device.c > @@ -297,8 +297,14 @@ static void lima_fini_gp_pipe(struct lima_device *dev) > { > struct lima_sched_pipe *pipe = dev->pipe + lima_pipe_gp; > > - lima_gp_pipe_fini(dev); > + cancel_work_sync(&pipe->recover_work); > + > lima_sched_pipe_fini(pipe); > + > + /* a recovery may have restarted the GP job */ > + lima_gp_stop(dev->ip + lima_ip_gp); > + > + lima_gp_pipe_fini(dev); > } > [ ... ] > @@ -442,17 +448,23 @@ void lima_device_fini(struct lima_device *ldev) > int i; > struct lima_sched_error_task *et, *tmp; > > + lima_fini_pp_pipe(ldev); > + > + /* free the IRQ sources of recover_work before the GP pipe drain */ > + lima_fini_ip(ldev, lima_ip_gp); > + lima_fini_ip(ldev, lima_ip_gpmmu); > + lima_fini_gp_pipe(ldev); [Severity: High] Could unregistering the IRQ handlers before draining the GP pipe lead to an unhandled interrupt storm? The call to lima_fini_gp_pipe() executes cancel_work_sync(&pipe->recover_work). If recover_work is executing concurrently during device teardown, cancel_work_sync() will wait for it to complete. The recovery work calls lima_gp_task_recover(), which explicitly unmasks the GP hardware interrupts and resumes hardware execution: gp_write(LIMA_GP_INT_MASK, LIMA_GP_IRQ_MASK_USED); When the hardware subsequently completes the job or faults, it will assert the IRQ line. Because the IRQ handler was already freed by the calls to lima_fini_ip() above, the interrupt goes unhandled. Could this cause the generic IRQ subsystem to permanently disable the shared IRQ line and break other devices sharing it? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
