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

[Vinod Koul <vkoul@kernel.org>]

On 18-09-26, 22:07, Koichiro Den wrote:
> On Thu, Sep 17, 2026 at 11:39:28AM -0500, Frank Li wrote:
> > On Thu, Sep 17, 2026 at 09:12:07AM +0200, Wolfram Sang wrote:
> > > From: Koichiro Den <den@valinux.co.jp>
> > >
> > > Call dma_descriptor_unmap() right after dma_cookie_complete() in the
> > > threaded IRQ completion path. Without this, streaming DMA mappings
> > > attached to the descriptor are never released and may eventually exhaust
> > > DMA mapping resources (e.g. IOVA with an IOMMU or bounce-buffer slots
> > > with SWIOTLB), leading to dma_map_* failures.
> > >
> > > Also ensure dma_descriptor_unmap() is called in rcar_dmac_chan_reinit()
> > > (error/terminate path) to avoid the same type of leaks.
> > >
> > > Fixes: 87244fe5abdf ("dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA Controller (DMAC) driver")
> > > Signed-off-by: Koichiro Den <den@valinux.co.jp>
> > > [wsa: added Fixes tag]
> > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > > ---
> > >  drivers/dma/sh/rcar-dmac.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> > > index 5b54f1c4ce15..9155bceb723b 100644
> > > --- a/drivers/dma/sh/rcar-dmac.c
> > > +++ b/drivers/dma/sh/rcar-dmac.c
> > > @@ -844,6 +844,7 @@ static void rcar_dmac_chan_reinit(struct rcar_dmac_chan *chan)
> > >
> > >  	list_for_each_entry_safe(desc, _desc, &descs, node) {
> > >  		list_del(&desc->node);
> > > +		dma_descriptor_unmap(&desc->async_tx);
> > >  		rcar_dmac_desc_put(chan, desc);
> > >  	}
> > >  }
> > > @@ -1654,6 +1655,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);
> > 
> > Does callback function still use these data? suppose should unmap after
> > callback return.
> 
> Unmapping doesn't free the buffer, so I don't think accessing the buffer in the
> callback requires that order. Correct me if I misinterpret your point.

Yep, we are not freeing, we are unmapping from dma. This can be and should be
done here.
-- 
~Vinod