[PATCH] dmaengine: qcom: hidma: fix autosuspend cleanup during teardown

[PATCH] dmaengine: qcom: hidma: fix autosuspend cleanup during teardown

[Guangshuo Li]

hidma_probe() calls pm_runtime_use_autosuspend(), but neither the probe
failure path nor hidma_remove() calls the matching
pm_runtime_dont_use_autosuspend() before disabling runtime PM.

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.

Add the missing pm_runtime_dont_use_autosuspend() calls to both the
probe failure and remove paths before disabling runtime PM.

This issue was found by manual code inspection.

Fixes: 67a2003e0607 ("dmaengine: add Qualcomm Technologies HIDMA channel driver")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
 drivers/dma/qcom/hidma.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index c939635be21d..78fd765c81e4 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -893,6 +893,7 @@ static int hidma_probe(struct platform_device *pdev)
 		hidma_free(dmadev);
 bailout:
 	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	return rc;
 }
@@ -930,6 +931,7 @@ static void hidma_remove(struct platform_device *pdev)
 
 	dev_info(&pdev->dev, "HI-DMA engine removed\n");
 	pm_runtime_put_sync_suspend(&pdev->dev);
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 }
 
-- 
2.43.0

Re: [PATCH] dmaengine: qcom: hidma: fix autosuspend cleanup during teardown

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The probe error path does not explicitly free the non-MSI interrupt before tearing down hardware data structures, leading to a potential Use-After-Free.
--

--- Patch [1]: [PATCH] dmaengine: qcom: hidma: fix autosuspend cleanup during teardown ---
commit 70b55f9899639dda5787b14a1ceb8890d7e7d005
Author: Guangshuo Li <lgs201920130244@gmail.com>

dmaengine: qcom: hidma: fix autosuspend cleanup during teardown

This patch fixes unbalanced usage counts during runtime PM teardown in the
Qualcomm HIDMA driver. It adds missing pm_runtime_dont_use_autosuspend() calls
to both the probe failure path and the device removal path.

> diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
> index 7a7f302a96991..d60d5f9a6182f 100644
> --- a/drivers/dma/qcom/hidma.c
> +++ b/drivers/dma/qcom/hidma.c
> @@ -894,6 +894,7 @@ static int hidma_probe(struct platform_device *pdev)
>  		hidma_free(dmadev);
>  bailout:
>  	pm_runtime_put_sync(&pdev->dev);
> +	pm_runtime_dont_use_autosuspend(&pdev->dev);

[Severity: High]
This is a pre-existing issue, but does the probe error path have a
use-after-free risk for the non-MSI interrupt?

Looking at the uninit path just above this in hidma_probe():

drivers/dma/qcom/hidma.c:hidma_probe() {
...
uninit:
	if (msi)
		hidma_free_msis(dmadev);

	hidma_ll_uninit(dmadev->lldev);
...
}

If this is not an MSI interrupt, it remains active when hidma_ll_uninit()
is called because it was registered with devm_request_irq().

The hidma_ll_uninit() function calls tasklet_kill(&lldev->task) while
the hardware interrupt is still enabled.

If an interrupt fires during this window, the ISR hidma_ll_inthandler()
can call hidma_post_completed(), which reschedules the tasklet via
tasklet_schedule(&lldev->task). 

Since devres will eventually free the IRQ and the lldev memory, could
the re-scheduled tasklet remain queued and execute later, dereferencing
the freed lldev pointer? 

Should the non-MSI interrupt be explicitly freed using devm_free_irq()
before calling hidma_ll_uninit()?

>  	pm_runtime_disable(&pdev->dev);
>  	return rc;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260808112551.2786782-1-lgs201920130244@gmail.com?part=1