All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: rolanddreier@rivian.com
Cc: Sudeep Holla <sudeep.holla@kernel.org>,
	Cristian Marussi <cristian.marussi@arm.com>,
	arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] firmware: arm_scmi: Don't reuse raw xfers with async_done still armed
Date: Tue, 8 Sep 2026 16:46:22 +0100	[thread overview]
Message-ID: <aqAtziZh1BGCaP9B@pluto> (raw)
In-Reply-To: <20260814-scmi-async-done-race-v1-2-335b163d77ee@rivian.com>

On Fri, Aug 14, 2026 at 08:15:34PM +0000, Roland Dreier via B4 Relay wrote:
> From: Roland Dreier <rolanddreier@rivian.com>
> 
> In SCMI raw mode, scmi_xfer_raw_worker() releases the xfer before
> releasing the waiter that disarms xfer->async_done, and scmi_xfer_get()
> does not clear async_done when it hands out a recycled xfer. A concurrent
> transaction can therefore pick up the xfer while it still points at the
> old waiter's completion, so:
> 
>  - a delayed response arriving for the new transaction can be signalled
>    on the old waiter's completion, which may already be re-armed for yet
>    another unrelated transaction, making that transaction's wait return
>    early; and
> 
>  - the old waiter's disarm, which still runs after the xfer has been
>    released, clobbers the arming just installed by the new transaction,
>    so the new waiter times out even if its delayed response arrives.
> 
> Release the waiter first, while the worker still holds a reference on
> the xfer, so that an xfer can never reach the free list still
> armed. Track whether a delayed response is expected in the waiter
> itself instead of peeking at xfer->async_done outside xfer->lock, and
> wait on the waiter's own embedded completion. (The new async flag is
> not strictly needed but it makes the logic easier to reason about)
> 
> Finally, harden scmi_xfer_get() to clear async_done when handing out
> an xfer, so that no future release-ordering change can leak a stale
> arming into a new transaction.
> 
> Fixes: 3c3d818a9317 ("firmware: arm_scmi: Add core raw transmission support")
> Signed-off-by: Roland Dreier <rolanddreier@rivian.com>

Hi,

thanks for this.

LGTM.

Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Tested-by: Cristian Marussi <cristian.marussi@arm.com>

Thanks,
Cristian

  reply	other threads:[~2026-09-08 15:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-14 20:15 [PATCH 0/2] Couple of SCMI race fixes Roland Dreier via B4 Relay
2026-08-14 20:15 ` Roland Dreier
2026-08-14 20:15 ` [PATCH 1/2] firmware: arm_scmi: Protect xfer->async_done with xfer->lock Roland Dreier via B4 Relay
2026-08-14 20:15   ` Roland Dreier
2026-08-14 20:15 ` [PATCH 2/2] firmware: arm_scmi: Don't reuse raw xfers with async_done still armed Roland Dreier via B4 Relay
2026-08-14 20:15   ` Roland Dreier
2026-09-08 15:46   ` Cristian Marussi [this message]
2026-08-29 17:53 ` [PATCH 0/2] Couple of SCMI race fixes Roland Dreier
2026-09-08 15:39 ` Cristian Marussi
  -- strict thread matches above, loose matches on Subject: below --
2026-08-12 22:43 [PATCH 1/2] firmware: arm_scmi: Protect xfer->async_done with xfer->lock Roland Dreier
2026-08-12 22:43 ` [PATCH 2/2] firmware: arm_scmi: Don't reuse raw xfers with async_done still armed Roland Dreier

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=aqAtziZh1BGCaP9B@pluto \
    --to=cristian.marussi@arm.com \
    --cc=arm-scmi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rolanddreier@rivian.com \
    --cc=sudeep.holla@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.