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
next prev parent 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.