[PATCH v2] dma: at_hdmac: Use stored IRQ in error path

[PATCH v2] dma: at_hdmac: Use stored IRQ in error path

[Hongling Zeng]

When request_irq() succeeds but a later error occurs in at_dma_probe(),
the error handling path attempts to free the IRQ by calling
platform_get_irq() again instead of using the already stored IRQ number
in the local variable 'irq'.

Use the stored 'irq' variable directly in free_irq() to make the
code clearer and eliminate smatch warnings about potential IRQ leaks.

While platform_get_irq() is deterministic, using the stored value
makes the error handling more robust against future code changes and
clearly shows the relationship between request_irq() and free_irq().

Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>

---
 Change in v2:
 -Add pre-review
---
 drivers/dma/at_hdmac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index e5b30a57c477..2a860679b9e1 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -2109,7 +2109,7 @@ static int __init at_dma_probe(struct platform_device *pdev)
 err_memset_pool_create:
 	dma_pool_destroy(atdma->lli_pool);
 err_desc_pool_create:
-	free_irq(platform_get_irq(pdev, 0), atdma);
+	free_irq(irq, atdma);
 err_irq:
 	clk_disable_unprepare(atdma->clk);
 	return err;
-- 
2.25.1

Re: [PATCH v2] dma: at_hdmac: Use stored IRQ in error path

[sashiko-bot]

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

Pre-existing issues:
- [High] The driver fails to kill the `virt-dma` tasklets during device removal and probe error handling, introducing a potential use-after-free vulnerability.
--

commit ec631cae7f09ccd02ee02a4198acec6059bb578b
Author: Hongling Zeng <zenghongling@kylinos.cn>

dma: at_hdmac: Use stored IRQ in error path

When request_irq() succeeds but a later error occurs in at_dma_probe(),
the error handling path attempts to free the IRQ by calling
platform_get_irq() again instead of using the already stored IRQ number.
This patch uses the stored 'irq' variable directly.

> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index e5b30a57c477a..2a860679b9e1c 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -2109,7 +2109,7 @@ static int __init at_dma_probe(struct platform_device *pdev)
>  err_memset_pool_create:
>  	dma_pool_destroy(atdma->lli_pool);
>  err_desc_pool_create:
> -	free_irq(platform_get_irq(pdev, 0), atdma);
> +	free_irq(irq, atdma);

[Severity: High]
This is a pre-existing issue, but does this error path (as well as
at_dma_remove()) fail to kill the virt-dma tasklets?

In at_dma_probe(), if an error occurs after channels are initialized via
vchan_init(), free_irq() will wait for the currently executing IRQ handler to
complete, but it does not wait for scheduled tasklets.

Because the struct at_dma memory is devm-managed, it will be automatically
freed shortly after the probe error path or at_dma_remove() completes. If a
scheduled tasklet executes after the device memory is freed, could this
cause a use-after-free regression?

Should the cleanup paths loop over the initialized channels and call
tasklet_kill(&chan->vc.task) to ensure tasklets are safely stopped?

>  err_irq:
>  	clk_disable_unprepare(atdma->clk);
>  	return err;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604073043.207844-1-zenghongling@kylinos.cn?part=1