From: sashiko-bot@kernel.org
To: Frank.Li@oss.nxp.com
Cc: dmaengine@vger.kernel.org, vkoul@kernel.org, imx@lists.linux.dev,
Frank.Li@kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v7 4/9] dmaengine: dw-edma: Use new .device_prep_config_sg() callback
Date: Thu, 21 May 2026 17:56:51 +0000 [thread overview]
Message-ID: <20260521175652.5A6D21F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260521-dma_prep_config-v7-4-1f73f4899883@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The `dw_edma_device_prep_config_sg` callback modifies channel configuration locklessly, breaking the atomicity guarantee expected by the DMA engine framework.
--
commit be13dc9c4b2aec5db6e6e0dc4003902282d50c88
Author: Frank Li <Frank.Li@nxp.com>
dmaengine: dw-edma: Use new .device_prep_config_sg() callback
This commit implements the new device_prep_config_sg() callback for the
dw-edma driver. It aims to combine configuration and descriptor preparation
into a single step.
> diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
> index c2feb3adc79fa..92572dd8131e6 100644
> --- a/drivers/dma/dw-edma/dw-edma-core.c
> +++ b/drivers/dma/dw-edma/dw-edma-core.c
[ ... ]
> @@ -577,10 +577,11 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
> }
>
> static struct dma_async_tx_descriptor *
> -dw_edma_device_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
> - unsigned int len,
> - enum dma_transfer_direction direction,
> - unsigned long flags, void *context)
> +dw_edma_device_prep_config_sg(struct dma_chan *dchan, struct scatterlist *sgl,
> + unsigned int len,
> + enum dma_transfer_direction direction,
> + unsigned long flags,
> + struct dma_slave_config *config)
> {
> struct dw_edma_transfer xfer;
>
> @@ -591,6 +592,9 @@ dw_edma_device_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
> xfer.flags = flags;
> xfer.type = EDMA_XFER_SCATTER_GATHER;
>
> + if (config && dw_edma_device_config(dchan, config))
> + return NULL;
[Severity: High]
Does this lockless configuration introduce a race condition?
The dmaengine_prep_config_sg_safe API is documented to be re-entrant and
skips acquiring the per-channel spinlock if the driver implements the
device_prep_config_sg callback, relying entirely on the driver to ensure
atomic configuration and descriptor preparation.
However, dw_edma_device_prep_config_sg() directly calls
dw_edma_device_config(), which mutates shared channel state (such as
chan->config, chan->non_ll, and chan->configured) without taking any
internal locks.
If multiple threads concurrently prepare transfers on the same channel,
these updates will race. This could lead to corrupted channel states where
dw_edma_device_transfer() may read interleaved or invalid parameters, such
as an incorrect non_ll flag.
Note that even if a subsequent patch in the series partially mitigates this
by passing the config object to resolve source and destination address races,
it still calls dw_edma_device_config() which locklessly modifies chan->non_ll
and chan->config, leaving the underlying race on the shared channel state
unresolved.
> +
> return dw_edma_device_transfer(&xfer);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260521-dma_prep_config-v7-0-1f73f4899883@nxp.com?part=4
next prev parent reply other threads:[~2026-05-21 17:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-21 15:32 [PATCH v7 0/9] dmaengine: Add new API to combine configuration and descriptor preparation Frank.Li
2026-05-21 15:32 ` [PATCH v7 1/9] dmaengine: Add API to combine configuration and preparation (sg and single) Frank.Li
2026-05-21 15:32 ` [PATCH v7 2/9] dmaengine: Add safe API to combine configuration and preparation Frank.Li
2026-05-21 17:10 ` sashiko-bot
2026-05-21 15:32 ` [PATCH v7 3/9] PCI: endpoint: pci-epf-test: Use dmaenigne_prep_config_single() to simplify code Frank.Li
2026-05-21 17:31 ` sashiko-bot
2026-07-09 19:52 ` Bjorn Helgaas
2026-07-14 12:11 ` Vinod Koul
2026-05-21 15:32 ` [PATCH v7 4/9] dmaengine: dw-edma: Use new .device_prep_config_sg() callback Frank.Li
2026-05-21 17:56 ` sashiko-bot [this message]
2026-05-21 15:32 ` [PATCH v7 5/9] dmaengine: dw-edma: Pass dma_slave_config to dw_edma_device_transfer() Frank.Li
2026-05-21 18:10 ` sashiko-bot
2026-05-21 15:32 ` [PATCH v7 6/9] nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer Frank.Li
2026-05-21 18:31 ` sashiko-bot
2026-05-21 15:32 ` [PATCH v7 7/9] nvmet: pci-epf: Use dmaengine_prep_config_single_safe() API Frank.Li
2026-05-21 19:05 ` sashiko-bot
2026-05-21 15:32 ` [PATCH v7 8/9] PCI: epf-mhi: Use dmaengine_prep_config_single() to simplify code Frank.Li
2026-05-21 15:32 ` [PATCH v7 9/9] crypto: atmel: Use dmaengine_prep_config_sg() API Frank.Li
2026-07-02 15:26 ` [PATCH v7 0/9] dmaengine: Add new API to combine configuration and descriptor preparation 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=20260521175652.5A6D21F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=Frank.Li@oss.nxp.com \
--cc=dmaengine@vger.kernel.org \
--cc=imx@lists.linux.dev \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vkoul@kernel.org \
/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.