All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jia Wang" <wangjia@ultrarisc.com>
Cc: vkoul@kernel.org, Frank.Li@kernel.org, dmaengine@vger.kernel.org
Subject: Re: [PATCH v3 4/4] dmaengine: dw-axi-dmac: Use bitfield helpers for registers
Date: Wed, 02 Sep 2026 09:39:09 +0000	[thread overview]
Message-ID: <20260902093909.7695A1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260902-dma-fix-v3-4-414c6449fbcc@ultrarisc.com>

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

Pre-existing issues:
- [High] Kernel crash in axi_desc_put due to dma_pool_free() being called with a NULL virtual address when descriptor setup fails.
--

commit cfefdb6fe5a6c1faad810fe6247a2229e7ffd900
Author: Jia Wang <wangjia@ultrarisc.com>

    dmaengine: dw-axi-dmac: Use bitfield helpers for registers
    
    The driver open-codes several channel configuration and descriptor
    control bitfield writes with left shifts. Define masks for those fields
    and use FIELD_PREP() when programming the registers.
    
    Valid field values keep the same encoding. FIELD_PREP() confines values
    to their respective fields, but does not validate handshake numbers
    supplied through DMA specifiers.

> diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> index 61230d2b1c561..b4aa6461684cb 100644
> --- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> +++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
[ ... ]
> @@ -977,19 +980,19 @@ dma_chan_prep_dma_memcpy(struct dma_chan *dchan, dma_addr_t dst_adr,
>  		if (chan->chip->dw->hdata->restrict_axi_burst_len) {
>  			u32 burst_len = chan->chip->dw->hdata->axi_rw_burst_len - 1;
>  
> -			reg |= (CH_CTL_H_ARLEN_EN |
> -				burst_len << CH_CTL_H_ARLEN_POS |
> -				CH_CTL_H_AWLEN_EN |
> -				burst_len << CH_CTL_H_AWLEN_POS);
> +			reg |= CH_CTL_H_ARLEN_EN |
> +			       FIELD_PREP(CH_CTL_H_ARLEN, burst_len) |
> +			       CH_CTL_H_AWLEN_EN |
> +			       FIELD_PREP(CH_CTL_H_AWLEN, burst_len);
>  		}
>  		hw_desc->lli->ctl_hi = cpu_to_le32(reg);
>  
> -		reg = (DWAXIDMAC_BURST_TRANS_LEN_4 << CH_CTL_L_DST_MSIZE_POS |
> -		       DWAXIDMAC_BURST_TRANS_LEN_4 << CH_CTL_L_SRC_MSIZE_POS |
> -		       xfer_width << CH_CTL_L_DST_WIDTH_POS |
> -		       xfer_width << CH_CTL_L_SRC_WIDTH_POS |
> -		       DWAXIDMAC_CH_CTL_L_INC << CH_CTL_L_DST_INC_POS |
> -		       DWAXIDMAC_CH_CTL_L_INC << CH_CTL_L_SRC_INC_POS);
> +		reg = FIELD_PREP(CH_CTL_L_DST_MSIZE, DWAXIDMAC_BURST_TRANS_LEN_4) |
> +		      FIELD_PREP(CH_CTL_L_SRC_MSIZE, DWAXIDMAC_BURST_TRANS_LEN_4) |
> +		      FIELD_PREP(CH_CTL_L_DST_WIDTH, xfer_width) |
> +		      FIELD_PREP(CH_CTL_L_SRC_WIDTH, xfer_width) |
> +		      FIELD_PREP(CH_CTL_L_DST_INC, DWAXIDMAC_CH_CTL_L_INC) |
> +		      FIELD_PREP(CH_CTL_L_SRC_INC, DWAXIDMAC_CH_CTL_L_INC);
>  		hw_desc->lli->ctl_lo = cpu_to_le32(reg);
>  
>  		set_desc_src_master(hw_desc);

[Severity: High]
This is a pre-existing issue, but can the error handling path in
dma_chan_prep_dma_memcpy() cause a kernel crash?

If axi_desc_get() fails to allocate a descriptor from the DMA pool, the code
jumps to err_desc_get and calls axi_desc_put(desc):

drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c:dma_chan_prep_dma_memcpy() {
	...
		hw_desc->lli = axi_desc_get(chan, &hw_desc->llp);
		if (unlikely(!hw_desc->lli))
			goto err_desc_get;
	...
err_desc_get:
	if (desc)
		axi_desc_put(desc);
	return NULL;
}

In axi_desc_put(), the loop unconditionally iterates over all requested
hardware descriptors up to desc->nr_hw_descs and attempts to free them:

drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c:axi_desc_put() {
	...
	for (descs_put = 0; descs_put < count; descs_put++) {
		hw_desc = &desc->hw_desc[descs_put];
		dma_pool_free(chan->desc_pool, hw_desc->lli, hw_desc->llp);
	}
	...
}

Because unallocated descriptors will have a NULL hw_desc->lli, dma_pool_free()
is called with a NULL virtual address. Since dma_pool_free() does not check
for a NULL vaddr input, will this trigger a NULL pointer dereference in the
DMA pool allocator?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902-dma-fix-v3-0-414c6449fbcc@ultrarisc.com?part=4

  reply	other threads:[~2026-09-02  9:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02  9:26 [PATCH v3 0/4] dmaengine: dw-axi-dmac: Fix burst encoding, LLI dump and priority Jia Wang
2026-09-02  9:26 ` [PATCH v3 1/4] dmaengine: dw-axi-dmac: Fix AXI burst length encoding Jia Wang
2026-09-02  9:39   ` sashiko-bot
2026-09-02  9:26 ` [PATCH v3 2/4] dmaengine: dw-axi-dmac: Fix LLI dump out-of-bounds access Jia Wang
2026-09-02  9:40   ` sashiko-bot
2026-09-02  9:26 ` [PATCH v3 3/4] dmaengine: dw-axi-dmac: Fix CH_CFG2 channel priority position Jia Wang
2026-09-02  9:40   ` sashiko-bot
2026-09-02  9:26 ` [PATCH v3 4/4] dmaengine: dw-axi-dmac: Use bitfield helpers for registers Jia Wang
2026-09-02  9:39   ` sashiko-bot [this message]
2026-09-02 16:08   ` Frank Li
2026-09-10 14:10 ` [PATCH v3 0/4] dmaengine: dw-axi-dmac: Fix burst encoding, LLI dump and priority Vinod Koul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260902093909.7695A1F00A3D@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vkoul@kernel.org \
    --cc=wangjia@ultrarisc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.