Re: [PATCH 2/3] dmaengine: rcar-dmac: Add missing dma_descriptor_unmap()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dmaengine: data corruption due to premature dma_cookie_complete() before unmap
--

commit 1e9a738c62158e887202df32a8267f4bc4bfe4cd
Author: Koichiro Den <den@valinux.co.jp>

dmaengine: rcar-dmac: Add missing dma_descriptor_unmap()

This commit adds missing calls to dma_descriptor_unmap() in the threaded IRQ
completion path and the channel reinit path. This prevents streaming DMA 
mappings from exhausting mapping resources.

> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index 2d2baa36feeae..016024858fe5a 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c

[ ... ]

> @@ -1652,6 +1653,7 @@ static irqreturn_t rcar_dmac_isr_channel_thread(int irq, void *dev)
>  		desc = list_first_entry(&chan->desc.done, struct rcar_dmac_desc,
>  					node);
>  		dma_cookie_complete(&desc->async_tx);
> +		dma_descriptor_unmap(&desc->async_tx);

[Severity: High]
Could this specific ordering lead to data corruption? 

By calling dma_cookie_complete() before dma_descriptor_unmap() in
rcar_dmac_isr_channel_thread(), polling clients (via dma_async_is_tx_complete()
or rcar_dmac_tx_status()) checking for completion locklessly might observe
the completion too early.

If they access the destination buffer before the unmap operation finishes
cache invalidations or SWIOTLB bounce buffer copies, it could result in
reading stale data.

Would it be safer to place dma_descriptor_unmap() strictly before
dma_cookie_complete() to prevent clients from seeing stale memory?

>  		list_del(&desc->node);
>  
>  		dmaengine_desc_get_callback(&desc->async_tx, &cb);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917071208.36888-1-wsa+renesas@sang-engineering.com?part=2