Re: [PATCHv3] dmaengine: fsldma: convert to platform_get_irq_optional()

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The return value of dma_async_device_register() is completely ignored, leading to silent failures and a potential zombie driver state that corrupts core DMA IDA state on removal.
- [High] Missing tasklet_kill() before freeing the DMA channel structure leads to a potential Use-After-Free if a tasklet is scheduled during teardown.
--

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

dmaengine: fsldma: convert to platform_get_irq_optional()

Replace the per-controller irq_of_parse_and_map() call with
platform_get_irq_optional(). The controller IRQ is optional when absent
and the driver falls back to per-channel IRQs.

> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index 22d62d958abd9..dd2937e443673 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c

[ ... ]

> @@ -1300,7 +1307,6 @@ static int fsldma_of_probe(struct platform_device *op)
>  		if (fdev->chan[i])
>  			fsl_dma_chan_remove(fdev->chan[i]);

[Severity: High]
This is a pre-existing issue, but does fsl_dma_chan_remove() fail to
explicitly kill the tasklet before freeing the channel structure?

During device removal or probe error paths, fsldma_free_irqs() calls
free_irq(). If a hardware interrupt executes just before free_irq(), it
schedules chan->tasklet. free_irq() waits for the hardirq handler to finish
but does not wait for pending softirqs.

The driver then calls fsl_dma_chan_remove() which invokes kfree(chan)
without calling tasklet_kill(&chan->tasklet).

When the softirq scheduler subsequently runs the tasklet, could
dma_do_tasklet() dereference the freed chan pointer and cause a
use-after-free?


[Severity: High]
This is another pre-existing issue, but does fsldma_of_probe() ignore the
return value of dma_async_device_register() just before this error path?

fsldma_of_probe() does this right before the out_free_fdev label:

    dma_async_device_register(&fdev->common);
    return 0;

If dma_async_device_register() fails, the driver returns success but the
device is not successfully registered. On driver teardown, fsldma_of_remove()
will call dma_async_device_unregister() with this unregistered device.

Could this lead to a double-free or mis-free in the IDA allocator, freeing
an ID it never successfully acquired and corrupting the DMA engine ID
namespace?

>  	}
> -	irq_dispose_mapping(fdev->irq);
>  	iounmap(fdev->regs);
>  out_free:
>  	kfree(fdev);

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