Re: [PATCH 1/3] dma: mv_xor: use devm_clk_get_optional_enabled

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The IRQ tasklet `mv_chan->irq_tasklet` is never canceled, leading to a Use-After-Free.
--

commit afdff052af38a51a1e801381a05797da055168c9
Author: Rosen Penev <rosenp@gmail.com>

dma: mv_xor: use devm_clk_get_optional_enabled

Replace clk_get + clk_prepare_enable + clk_put with
devm_clk_get_optional_enabled. This eliminates the need for
manual clock cleanup in the probe error path.

> diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
> --- a/drivers/dma/mv_xor.c
> +++ b/drivers/dma/mv_xor.c
[ ... ]
> @@ -1452,11 +1449,6 @@ static int mv_xor_probe(struct platform_device *pdev)
>  				irq_dispose_mapping(xordev->channels[i]->irq);
>  		}
>  
> -	if (!IS_ERR(xordev->clk)) {
> -		clk_disable_unprepare(xordev->clk);
> -		clk_put(xordev->clk);
> -	}
> -

[Severity: High]
This is a pre-existing issue, but does mv_xor_channel_remove() leave a
tasklet pending when called from this probe error path?

If the probe fails and jumps to err_channel_add, the cleanup loop calls
mv_xor_channel_remove() which tears down the channel:

drivers/dma/mv_xor.c:mv_xor_channel_remove() {
        dma_async_device_unregister(&mv_chan->dmadev);
        dma_unmap_single(...)
        dma_unmap_single(...)
        ...
        return 0;
}

However, it doesn't appear to call tasklet_kill() to cancel
mv_chan->irq_tasklet.

Since mv_chan is allocated with devres, returning from the probe error path
will automatically free the channel structure. If an interrupt fires and
schedules the tasklet during teardown, could it execute asynchronously after
devres has freed mv_chan, resulting in a use-after-free?

>  	return ret;
>  }

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