[PATCH] drm/etnaviv: fix runtime PM cleanup during teardown

[PATCH] drm/etnaviv: fix runtime PM cleanup during teardown

[Guangshuo Li]

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().

If the autosuspend delay is set to a negative value while autosuspend
is enabled, the runtime PM core increments usage_count to prevent
runtime suspend. Without calling pm_runtime_dont_use_autosuspend()
during teardown, this reference is not dropped and usage_count remains
unbalanced.

The documentation for pm_runtime_use_autosuspend() also notes that it
is important to undo it with pm_runtime_dont_use_autosuspend() at
driver exit time, unless runtime PM was initially enabled with
devm_pm_runtime_enable().

Undo the autosuspend setting on both probe failure and device removal,
and disable runtime PM on the component registration failure path.

This issue was found by manual code inspection.

Fixes: a8c21a5451d8 ("drm/etnaviv: add initial etnaviv DRM driver")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index c314b3cb5e70..7acf2ed651f3 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1964,6 +1964,8 @@ static int etnaviv_gpu_platform_probe(struct platform_device *pdev)
 	err = component_add(dev, &gpu_ops);
 	if (err < 0) {
 		dev_err(dev, "failed to register component: %d\n", err);
+		pm_runtime_dont_use_autosuspend(dev);
+		pm_runtime_disable(dev);
 		return err;
 	}
 
@@ -1975,6 +1977,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);
-- 
2.43.0

Re: [PATCH] drm/etnaviv: fix runtime PM cleanup during teardown

[sashiko-bot]

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 <lgs201920130244@gmail.com>

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/20260808121434.2815841-1-lgs201920130244@gmail.com?part=1