From: Roland Dreier <rolanddreier@rivian.com>
To: Sudeep Holla <sudeep.holla@kernel.org>,
Cristian Marussi <cristian.marussi@arm.com>
Cc: arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: [PATCH 2/2] firmware: arm_scmi: Don't reuse raw xfers with async_done still armed
Date: Wed, 12 Aug 2026 22:43:06 +0000 [thread overview]
Message-ID: <20260812224311.904964-2-rolanddreier@rivian.com> (raw)
In-Reply-To: <20260812224311.904964-1-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>
---
drivers/firmware/arm_scmi/driver.c | 1 +
drivers/firmware/arm_scmi/raw_mode.c | 25 +++++++++++++++++++++----
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 5c295bdc15ca..2d8884f0036b 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -717,6 +717,7 @@ static struct scmi_xfer *scmi_xfer_get(const struct scmi_handle *handle,
refcount_set(&xfer->users, 1);
atomic_set(&xfer->busy, SCMI_XFER_FREE);
+ xfer->async_done = NULL;
spin_unlock_irqrestore(&minfo->xfer_lock, flags);
return xfer;
diff --git a/drivers/firmware/arm_scmi/raw_mode.c b/drivers/firmware/arm_scmi/raw_mode.c
index 8751cff5fa4e..5ee21f6b7001 100644
--- a/drivers/firmware/arm_scmi/raw_mode.c
+++ b/drivers/firmware/arm_scmi/raw_mode.c
@@ -198,6 +198,8 @@ struct scmi_raw_mode_info {
* @async_response: A completion to be, optionally, used for async waits: it
* will be setup by @scmi_do_xfer_raw_start, if needed, to be
* pointed at by xfer->async_done.
+ * @async: True if @async_response was armed on @xfer, i.e. if a delayed
+ * response has to be waited for.
* @node: A list node.
*/
struct scmi_xfer_raw_waiter {
@@ -205,6 +207,7 @@ struct scmi_xfer_raw_waiter {
struct scmi_chan_info *cinfo;
struct scmi_xfer *xfer;
struct completion async_response;
+ bool async;
struct list_head node;
};
@@ -349,6 +352,7 @@ scmi_xfer_raw_waiter_get(struct scmi_raw_mode_info *raw, struct scmi_xfer *xfer,
scmi_xfer_async_response_arm(xfer, &rw->async_response);
}
+ rw->async = async;
rw->cinfo = cinfo;
rw->xfer = xfer;
}
@@ -361,8 +365,16 @@ static void scmi_xfer_raw_waiter_put(struct scmi_raw_mode_info *raw,
struct scmi_xfer_raw_waiter *rw)
{
if (rw->xfer) {
+ /*
+ * Disarm the delayed response before this waiter, and its
+ * embedded completion, can be picked up again for a new
+ * transaction: a delayed response received late, after the
+ * related wait timed out, must not signal a completion which
+ * has been in the meantime re-armed on a different xfer.
+ */
scmi_xfer_async_response_disarm(rw->xfer);
rw->xfer = NULL;
+ rw->async = false;
}
mutex_lock(&raw->free_mtx);
@@ -479,18 +491,23 @@ static void scmi_xfer_raw_worker(struct work_struct *work)
ret, scmi_inflight_count(raw->handle));
/* Wait also for an async delayed response if needed */
- if (!ret && xfer->async_done) {
+ if (!ret && rw->async) {
unsigned long tmo = msecs_to_jiffies(SCMI_MAX_RESPONSE_TIMEOUT);
- if (!wait_for_completion_timeout(xfer->async_done, tmo))
+ if (!wait_for_completion_timeout(&rw->async_response, tmo))
dev_err(dev,
"timed out in RAW delayed resp - HDR:%08X\n",
pack_scmi_header(&xfer->hdr));
}
- /* Release waiter and xfer */
- scmi_xfer_raw_put(raw->handle, xfer);
+ /*
+ * Release the waiter first: this disarms the delayed response
+ * while we still hold a reference on the xfer, so that the xfer
+ * cannot be recycled by a new transaction while it still points
+ * at this waiter's completion.
+ */
scmi_xfer_raw_waiter_put(raw, rw);
+ scmi_xfer_raw_put(raw->handle, xfer);
} while (1);
}
--
2.54.0
--
*CONFIDENTIALITY NOTE:* This electronic message (including any attachments)
may contain information that is privileged, confidential, and proprietary.
If you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or use of the information contained
herein (including any reliance thereon) is strictly prohibited. If you
received this electronic message in error, please immediately reply to the
sender that you have received this communication and destroy the material
in its entirety, whether in electronic or hard copy format. Although Rivian
has taken reasonable precautions to ensure no viruses are present in this
email, Rivian accepts no responsibility for any loss or damage arising from
the use of this email or attachments.
next prev parent reply other threads:[~2026-08-12 22:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
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 ` Roland Dreier [this message]
2026-08-13 10:14 ` Cristian Marussi
-- strict thread matches above, loose matches on Subject: below --
2026-08-14 20:15 [PATCH 0/2] Couple of SCMI race fixes Roland Dreier via B4 Relay
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
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=20260812224311.904964-2-rolanddreier@rivian.com \
--to=rolanddreier@rivian.com \
--cc=arm-scmi@vger.kernel.org \
--cc=cristian.marussi@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox