Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Workqueue `gpu->wq` is destroyed before the GPU is quiesced, leading to a Use-After-Free/kernel panic if an interrupt fires during unbind. -- --- Patch [1]: [PATCH] drm/etnaviv: fix runtime PM cleanup during teardown --- commit 77333bf2f506b75e91ec774e0e32c5f41714ae15 Author: Guangshuo Li <[email protected]> drm/etnaviv: fix runtime PM cleanup during teardown etnaviv_gpu_platform_probe() calls pm_runtime_use_autosuspend() and enables runtime PM before registering the component. If component_add() fails, the probe path returns without undoing the autosuspend setting or disabling runtime PM. The remove path also disables runtime PM without calling the matching pm_runtime_dont_use_autosuspend(). > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c > b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c > index 5c23182f4d33a..cf71e43614f84 100644 > --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c [ ... ] > @@ -1992,6 +1994,7 @@ static void etnaviv_gpu_platform_remove(struct > platform_device *pdev) > struct etnaviv_gpu *gpu = dev_get_drvdata(&pdev->dev); > > component_del(&pdev->dev, &gpu_ops); > + pm_runtime_dont_use_autosuspend(&pdev->dev); > pm_runtime_disable(&pdev->dev); > > mutex_destroy(&gpu->lock); [Severity: High] This is a pre-existing issue, but since this patch fixes teardown paths, can this component teardown sequence lead to a use-after-free? Looking at etnaviv_gpu_unbind(), which is called via component_del(), it destroys the workqueue before stopping the scheduler and quiescing the hardware: destroy_workqueue(gpu->wq); etnaviv_sched_fini(gpu); If an active GPU workload completes precisely in this window, the hardware raises an interrupt and irq_handler() executes: queue_work(gpu->wq, &gpu->sync_point_work); Does queuing work to a destroyed workqueue cause a kernel panic here? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
