Re: [PATCHv2] dmaengine: at_hdmac: fix sparse '__iomem' cast warning in memset helpers

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

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but atc_prep_dma_memset_sg() fails to broadcast the byte value into a 32-bit pattern, leading to incorrect memory fills.
- [High] This problem wasn't introduced by this patch, but there is a guaranteed kernel oops on error paths of DMA prep functions due to dereferencing an uninitialized vd->tx.chan pointer in atdma_desc_free().
--

--- Patch [1]: [PATCHv2] dmaengine: at_hdmac: fix sparse '__iomem' cast warning in memset helpers ---
commit e39a1989ac7867eaa551256bdc408f22e82b835b
Author: Rosen Penev <[email protected]>

dmaengine: at_hdmac: fix sparse '__iomem' cast warning in memset helpers

This patch changes the type of vaddr in memset helpers to avoid sparse
warnings about casting away the __iomem address space. It also updates the
memset_vaddr field in struct at_desc to match the actual usage.

Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/

> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index e5b30a57c477a..7c071e6496371 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c

[ ... ]

> @@ -1189,7 +1189,7 @@ atc_prep_dma_memset_sg(struct dma_chan *chan,
>  			__func__);
>  		return NULL;
>  	}
> -	*(u32*)vaddr = value;
> +	*vaddr = value;

[Severity: High]
This problem wasn't introduced by this patch, but does this correctly format
the fill pattern?

If atc_prep_dma_memset_sg() is called with a non-zero byte value (e.g., 0xAA),
the hardware memset pool buffer is initialized with the unexpanded 32-bit word
(0x000000AA). Because the controller repeatedly copies this 32-bit word to the
destination buffer in 4-byte chunks, the resulting memory is filled with an
incorrect pattern.

In atc_prep_dma_memset(), the value is correctly expanded into a 32-bit
pattern before assignment. Should atc_prep_dma_memset_sg() do the same?

>  
>  	desc = kzalloc_flex(*desc, sg, sg_len, GFP_ATOMIC);
>  	if (!desc)

[Severity: High]
This isn't a bug introduced by this patch, but will the error paths after this
allocation cause a NULL pointer dereference?

If a failure occurs later in this function, such as when checking buffer
alignment, the code jumps to err_free_desc and calls atdma_desc_free().

Since desc was allocated via kzalloc_flex() and vchan_tx_prep() has not yet
initialized the virtual channel structure, vd->tx.chan is NULL.

atdma_desc_free() immediately dereferences it:

atdma_desc_free()
    struct at_dma *atdma = to_at_dma(vd->tx.chan->device);

Could this crash the kernel under memory pressure or when invalid scatterlists
are passed?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1