Re: [PATCH] dmaengine: qcom_hidma: Fix runtime PM leak in hidma_issue_task()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dmaengine: qcom_hidma: stranded active descriptors on pm_runtime_get_sync() failure
--

commit 77de19698670459fd2543b487a29198a77d2c2e6
Author: Wentao Liang <vulab@iscas.ac.cn>

dmaengine: qcom_hidma: Fix runtime PM leak in hidma_issue_task()

This commit fixes a runtime PM usage counter leak in hidma_issue_task() by
checking the return value of pm_runtime_get_sync(). If it fails, it drops
the counter with pm_runtime_put_noidle() and returns early to avoid starting
the transfer.

> diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
> index c939635be21d2..5ed6c77e2b212 100644
> --- a/drivers/dma/qcom/hidma.c
> +++ b/drivers/dma/qcom/hidma.c
> @@ -219,7 +219,10 @@ static void hidma_issue_task(struct tasklet_struct *t)
>  {
>  	struct hidma_dev *dmadev = from_tasklet(dmadev, t, task);
>  
> -	pm_runtime_get_sync(dmadev->ddev.dev);
> +	if (pm_runtime_get_sync(dmadev->ddev.dev) < 0) {
> +		pm_runtime_put_noidle(dmadev->ddev.dev);
> +		return;

[Severity: Medium]
Does this early return leave active descriptors stranded without cleaning
them up?

When a DMA client queues a transaction, the descriptors are moved to the
active list before hidma_issue_task() is scheduled. Aborting the state
machine here without initiating the hardware transfer or failing the
descriptors can leave them permanently stuck.

This could cause DMA clients to hang indefinitely while waiting for
completion callbacks that will never arrive.

> +	}
>  	hidma_ll_start(dmadev->lldev);
>  }
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260916093032.2003397-1-vulab@iscas.ac.cn?part=1