Noticed a couple of races in SCMI code around delayed responses that
time out. These are probably nearly impossible to hit in practice but
the fixes are pretty straightforward and it seems worth having the
code be sound.
The v1 fixes were correct as posted, despite Sashiko warning that the
new "delayed_response_dropped" debug counter might never increment.
However, that review made me think that a new debug counter for a
one-in-a-gazillion race condition is probably less useful than a
kernel error message. So the change in v2 is having the first patch
log an error for a delayed response that arrives in the race window it
closes (matching the existing "Delayed Response not expected" error in
scmi_msg_response_validate()). The new error is expected to be
extremely rare but it makes sure there is no path where a delayed
response gets matched and then discarded without any logging.
Signed-off-by: Roland Dreier <rolanddreier@rivian.com>
---
Changes in v2:
- Patch 1: replace the new delayed_response_dropped debugfs counter
with a dev_err() log message, since the condition is rare enough
that logging is more useful than counting (per sashiko review of v1).
- Link to v1: https://patch.msgid.link/20260814-scmi-async-done-race-v1-0-335b163d77ee@rivian.com
To: Sudeep Holla <sudeep.holla@kernel.org>
To: Cristian Marussi <cristian.marussi@arm.com>
Cc: arm-scmi@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
Roland Dreier (2):
firmware: arm_scmi: Protect xfer->async_done with xfer->lock
firmware: arm_scmi: Don't reuse raw xfers with async_done still armed
drivers/firmware/arm_scmi/common.h | 22 ++++++++++++++++++++
drivers/firmware/arm_scmi/driver.c | 38 ++++++++++++++++++++++++++++++-----
drivers/firmware/arm_scmi/protocols.h | 9 ++++++---
drivers/firmware/arm_scmi/raw_mode.c | 29 ++++++++++++++++++++------
4 files changed, 84 insertions(+), 14 deletions(-)
---
base-commit: 786262be6048deab760f68c8acc2c85607165894
change-id: 20260814-scmi-async-done-race-29117fd1e9a5
Best regards,
--
Roland Dreier <rolanddreier@rivian.com>