Re: [PATCH v4 1/2] dmaengine: change dmaengine_get_unmap_data() first arg to dma_chan

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] dmaengine: Mismatched DMA device used for mapping and unmapping
- [High] dmaengine: NULL pointer dereference in dmaengine_get_dma_device() during mv_xor probe
--

commit 811fe2fcd19af9f3eb46610a12e2d1dc77b628e0
Author: Frank Li <Frank.Li@nxp.com>

dmaengine: change dmaengine_get_unmap_data() first arg to dma_chan

This commit modifies dmaengine_get_unmap_data() to accept a dma_chan
instead of a device pointer, automatically resolving the correct DMA device
for the channel. It updates various callers in the crypto, NTB, and DMA
test subsystems to match this new signature.

Link: https://lore.kernel.org/dmaengine/20260923-dmaengine_prep_dma_pq-v2-0-32ed65b8a9b4@nxp.com/
Link: https://lore.kernel.org/imx/b40fa0d7-fbd0-4ee8-b99c-781d08c18838@intel.com/T/#t

> diff --git a/crypto/async_tx/async_memcpy.c b/crypto/async_tx/async_memcpy.c
> --- a/crypto/async_tx/async_memcpy.c
> +++ b/crypto/async_tx/async_memcpy.c
> @@ -39,8 +39,8 @@
>  	struct dma_async_tx_descriptor *tx = NULL;
>  	struct dmaengine_unmap_data *unmap = NULL;
>  
> -	if (device)
> -		unmap = dmaengine_get_unmap_data(device->dev, 2, GFP_NOWAIT);
> +	if (chan)
> +		unmap = dmaengine_get_unmap_data(chan, 2, GFP_NOWAIT);

[Severity: High]
Will this create a DMA API mapping mismatch for systems with per-channel IOMMUs?

The updated dmaengine_get_unmap_data() now sets unmap->dev using
dmaengine_get_dma_device(chan). If the channel supports a per-channel IOMMU,
this correctly resolves to the channel's specific device.

However, the memory mapping calls later in async_memcpy() still use the parent
device:

unmap->addr[0] = dma_map_page(device->dev, src, src_offset, len,
                              DMA_TO_DEVICE);

When the operation finishes, dmaengine_unmap() will attempt to unmap the
memory from unmap->dev (the child IOMMU device), while it was mapped to
device->dev (the parent device). This asymmetry can cause stranded IOMMU
mappings and invalid unmap page faults.

A similar mismatch appears in drivers/ntb/ntb_transport.c in
ntb_async_rx_submit(), which maps using device->dev instead of resolving
through the channel.

[ ... ]

> 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
> @@ -789,7 +789,7 @@
>  		goto out;
>  	}
>  
> -	unmap = dmaengine_get_unmap_data(dma_chan->device->dev, 2, GFP_KERNEL);
> +	unmap = dmaengine_get_unmap_data(dma_chan, 2, GFP_KERNEL);

[Severity: High]
Does this introduce a NULL pointer dereference during device probe?

In the mv_xor driver, mv_chan_memcpy_self_test() is called during driver
initialization via mv_xor_channel_add(). This happens before the channel
is fully registered with the DMA core.

At this point, the channel's sysfs device pointer chan->dev is not yet
allocated. When this patch changes the call to pass dma_chan instead of
dma_chan->device->dev, the implementation of dmaengine_get_unmap_data() will
call dmaengine_get_dma_device(chan).

Looking at include/linux/dmaengine.h:

static inline struct device *dmaengine_get_dma_device(struct dma_chan *chan)
{
        if (chan->dev->chan_dma_dev)
                return &chan->dev->device;
        return chan->device->dev;
}

This unconditionally dereferences chan->dev, which is NULL during the
self-test, preventing the mv_xor driver from loading.

>  	if (!unmap) {
>  		err = -ENOMEM;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015155118.3063149-1-Frank.Li@oss.nxp.com?part=1