DMA Engine development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Eugen Hristev" <ehristev@kernel.org>
Cc: dmaengine@vger.kernel.org, vkoul@kernel.org, Frank.Li@kernel.org
Subject: Re: [PATCH] dmaengine: pl330: Bound UNTIL loop
Date: Wed, 04 Nov 2026 21:51:33 +0000	[thread overview]
Message-ID: <sashiko-outbox-198158@kernel.org> (raw)
In-Reply-To: <20261104-b4-pl330-until-v1-1-b541929da163@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dmaengine: pl330: second MMIO read in UNTIL() can miss transient state
--

commit ec02cf0a6d8895f26c57f9c3aaba3b3bd470e676
Author: Eugen Hristev <ehristev@kernel.org>

dmaengine: pl330: Bound UNTIL loop

This commit bounds the UNTIL macro loop with a timeout budget and checks its
return value in pl330_start_thread() to prevent the driver from hanging if a
bus fault leaves a DMA thread stuck in a transitional state.

> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index c2d0b473b8f48..9ced60fef9ffb 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -248,8 +248,15 @@ enum pl330_byteswap {
>   */
>  #define MCODE_BUFF_PER_REQ	256
>  
> -/* Use this _only_ to wait on transient states */
> -#define UNTIL(t, s)	while (!(_state(t) & (s))) cpu_relax();
> +/* returns true if state reached within loop budget */
> +#define UNTIL(t, s, loops) \
> +	({ \
> +		unsigned long _l = (loops); \
> +		while (!(_state(t) & (s)) && _l) { \
> +			cpu_relax(); _l--; \
> +		 } \
> +		!!(_state(t) & (s)); \
> +	 })

[ ... ]

> @@ -1059,12 +1067,24 @@ static bool _trigger(struct pl330_thread *thrd)
>  
>  static bool pl330_start_thread(struct pl330_thread *thrd)
>  {
> +	/* msecs_to_loops(5) gives the same budget used by _until_dmac_idle */
> +	const unsigned long tout = msecs_to_loops(5);
> +
>  	switch (_state(thrd)) {
>  	case PL330_STATE_FAULT_COMPLETING:
> -		UNTIL(thrd, PL330_STATE_FAULTING | PL330_STATE_KILLING);
> +		if (!UNTIL(thrd, PL330_STATE_FAULTING | PL330_STATE_KILLING,
> +			   tout)) {
> +			dev_err(thrd->dmac->ddma.dev,
> +				"pl330: thread stuck in FAULT_COMPLETING\n");
> +			return false;
> +		}
>  
>  		if (_state(thrd) == PL330_STATE_KILLING)
> -			UNTIL(thrd, PL330_STATE_STOPPED)
> +			if (!UNTIL(thrd, PL330_STATE_STOPPED, tout)) {
> +				dev_err(thrd->dmac->ddma.dev,
> +					"pl330: thread stuck KILLING->STOPPED\n");
> +				return false;
> +			}

[Severity: Medium]
Each invocation of _state(thrd) performs an MMIO readl() of the hardware
status register (DS or CS(thrd->id)).

In UNTIL(), after the while loop exits because (_state(t) & (s)) matched, the
macro performs a second MMIO read via !!(_state(t) & (s)) to compute the
return value.

In pl330_start_thread() under PL330_STATE_FAULT_COMPLETING, UNTIL() waits for
PL330_STATE_FAULTING | PL330_STATE_KILLING. Because PL330_STATE_KILLING is a
transient state that automatically transitions to PL330_STATE_STOPPED, what
happens if the while condition observes PL330_STATE_KILLING and exits the
loop, and the hardware finishes transitioning to PL330_STATE_STOPPED before
the trailing !!(_state(t) & (s)) read executes?

Wouldn't the second _state(t) read return PL330_STATE_STOPPED, causing UNTIL()
to evaluate to false and making pl330_start_thread() report a false timeout
and fail to start the thread?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261104-b4-pl330-until-v1-1-b541929da163@kernel.org?part=1

      reply	other threads:[~2026-11-04 21:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-04 21:45 [PATCH] dmaengine: pl330: Bound UNTIL loop Eugen Hristev
2026-11-04 21:51 ` sashiko-bot [this message]

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=sashiko-outbox-198158@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=ehristev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox