From: sashiko-bot@kernel.org
To: "Jean-Michel Hautbois" <jeanmichel.hautbois@yoseli.org>
Cc: vkoul@kernel.org, dmaengine@vger.kernel.org, imx@lists.linux.dev,
Frank.Li@kernel.org
Subject: Re: [PATCH v3 1/5] dmaengine: fsl-edma: Move error handler out of header file
Date: Thu, 25 Jun 2026 09:18:14 +0000 [thread overview]
Message-ID: <20260625091816.E43C31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260625-b4-edma-dmaengine-v3-1-44be00ace37d@yoseli.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Unprotected write to channel status in the error handler causes a data race that can mask hardware errors and hang DMA clients.
--
commit cc17ac4f2b0c85f5476ae3803d0c9e31bd371d29
Author: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
dmaengine: fsl-edma: Move error handler out of header file
This commit moves the fsl_edma_err_chan_handler function from an inline
definition in the header file to the common C file. This prepares the
driver for MCF ColdFire eDMA support, where the handler is called from
a specific interrupt handler.
> diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-common.c
> index bb7531c456dfa..1b1a0496b5e6f 100644
> --- a/drivers/dma/fsl-edma-common.c
> +++ b/drivers/dma/fsl-edma-common.c
> @@ -44,6 +44,11 @@
> #define EDMA64_ERRH 0x28
> #define EDMA64_ERRL 0x2c
>
> +void fsl_edma_err_chan_handler(struct fsl_edma_chan *fsl_chan)
> +{
> + fsl_chan->status = DMA_ERROR;
> +}
> +
[Severity: High]
This is a pre-existing issue, but does this unlocked write to the channel
status create a race condition that could mask hardware errors?
If fsl_edma_tx_chan_handler() processes a completed transfer on CPU0, it
calls fsl_edma_xfer_desc() to start the next pending transfer. This enables
the hardware request and then assigns the channel status to DMA_IN_PROGRESS.
If the new transfer immediately triggers a hardware error, the error
interrupt fires on CPU1. CPU1 executes fsl_edma_err_chan_handler() and
writes DMA_ERROR to fsl_chan->status without acquiring the vchan.lock.
If CPU1's write occurs between the hardware request being enabled and CPU0's
write to DMA_IN_PROGRESS, the DMA_ERROR state is overwritten.
If the error is masked, the driver state remains DMA_IN_PROGRESS while the
hardware is permanently halted. Could this cause DMA clients to hang
indefinitely waiting for the failed transfer?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625-b4-edma-dmaengine-v3-0-44be00ace37d@yoseli.org?part=1
next prev parent reply other threads:[~2026-06-25 9:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 8:59 [PATCH v3 0/5] dmaengine: mcf-edma: fix 64-channel handling and modernize IRQ setup Jean-Michel Hautbois
2026-06-25 8:59 ` [PATCH v3 1/5] dmaengine: fsl-edma: Move error handler out of header file Jean-Michel Hautbois
2026-06-25 9:18 ` sashiko-bot [this message]
2026-06-25 15:33 ` Frank Li
2026-06-25 8:59 ` [PATCH v3 2/5] dmaengine: fsl-edma: Add FSL_EDMA_DRV_MCF flag for ColdFire eDMA Jean-Michel Hautbois
2026-06-25 9:20 ` sashiko-bot
2026-06-25 15:16 ` Frank Li
2026-06-25 8:59 ` [PATCH v3 3/5] dmaengine: mcf-edma: Fix interrupt handler for 64 DMA channels Jean-Michel Hautbois
2026-06-25 15:30 ` Frank Li
2026-06-25 8:59 ` [PATCH v3 4/5] dmaengine: mcf-edma: Fix error handler for all " Jean-Michel Hautbois
2026-06-25 9:17 ` sashiko-bot
2026-06-25 15:23 ` Frank Li
2026-06-25 8:59 ` [PATCH v3 5/5] dmaengine: mcf-edma: Use devm for per-channel IRQ registration Jean-Michel Hautbois
2026-06-25 9:21 ` sashiko-bot
2026-06-25 15:26 ` Frank Li
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=20260625091816.E43C31F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=imx@lists.linux.dev \
--cc=jeanmichel.hautbois@yoseli.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.