From: Muralidhara M K <muralidhara.mk@amd.com>
To: <ilpo.jarvinen@linux.intel.com>
Cc: <platform-driver-x86@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <muthusamy.ramalingam@amd.com>,
Muralidhara M K <muralidhara.mk@amd.com>
Subject: [PATCH v3 0/5] platform/x86/amd/hsmp: ACPI/platform HSMP concurrency and lifecycle hardening
Date: Tue, 7 Jul 2026 10:45:34 +0530 [thread overview]
Message-ID: <20260707051534.3381387-1-muralidhara.mk@amd.com> (raw)
This series hardens the AMD HSMP ACPI and platform drivers against
probe/remove concurrency, use-after-free of the per-socket state, and
resource leaks across unbind/rebind cycles.
On multi-socket systems several ACPI platform devices are probed and
removed independently while a single /dev/hsmp and the hwmon sysfs
attributes drive a lock-free data plane. The existing code raced the
global is_probed handshake and the one-time socket allocation, freed the
socket array from under in-flight hsmp_send_message() callers, and leaked
metric-table mappings on rebind.
It sits on top of the ACPI mailbox-parsing and data-plane readiness
cleanups (base commit ff7836fa, "Gate the data plane on a fully
initialized socket").
The patches, in order:
1. Serialize ACPI probe/remove/init_acpi() with a dedicated mutex so the
is_probed handshake and the one-time socket allocation cannot race.
2. Map the metric-table DRAM explicitly with ioremap() and unmap it from
the driver teardown paths, so the mapping is no longer pinned to a
per-socket devres scope and the ACPI side can coordinate its release.
3. Serialize per-socket metric-table reads with a mutex so two concurrent
metrics_bin readers cannot have one trigger a fresh firmware fill while
the other is mid-copy and return a torn snapshot. The mutex is
initialized on both the platform and ACPI probe paths in this same
patch so no bisection point reads metrics_bin through an uninitialized
lock.
4. Replace the global is_probed flag with refcounted ACPI socket
ownership (a probe-mutex-guarded counter) and run a coordinated release
on the last unbind: deregister /dev/hsmp, unmap the metric DRAM,
destroy the per-socket mutexes and free the socket array. Also drop a
stale metric-table mapping before remapping on rebind, and stop
parenting the shared /dev/hsmp to a per-socket device.
5. Add hsmp_sock_rwsem so the lock-free data plane (hsmp_send_message()
and its MMIO access) is drained and kept out while a socket is torn
down; wire both the platform and ACPI teardown paths into it, nested
inside the ACPI probe mutex.
Testing:
- Each patch builds individually with no new warnings; the series is
bisectable.
- checkpatch.pl --strict --codespell is clean on every patch.
Changes since v2:
- Split the old "Add explicit metric DRAM mapping and per-socket mutexes"
patch into two single-purpose patches: the ioremap()/unmap mapping
change (patch 2) and the per-socket read-serialization mutex (patch 3).
- Replaced the struct kref ACPI socket refcount with a simpler counter
guarded by the existing probe mutex, and folded the coordinated
release, the stale-metric-mapping-on-rebind fix and the /dev/hsmp
parent fix into that one patch (patch 4).
- Decoupled the metric-table unmap (hsmp_unmap_metric_tbls()) from the
mutex teardown (hsmp_destroy_metric_read_locks()) so each helper does
exactly one thing.
- Wired the ACPI metric-read mutex init/destroy in the same patch that
introduces the mutex, closing a bisection window where an ACPI
metrics_bin read could lock an uninitialized mutex.
- Reordered the series so all hsmp_sock_rwsem writers (platform and ACPI
teardown) land together in the final patch.
v2: https://lore.kernel.org/platform-driver-x86/eb609912-1c42-6354-22e6-5ffd1f097e9f@linux.intel.com/T/#t
Muralidhara M K (5):
platform/x86/amd/hsmp: Serialize ACPI HSMP is_probed with a probe
mutex
platform/x86/amd/hsmp: Map the metric table with ioremap() and unmap
it explicitly
platform/x86/amd/hsmp: Serialize per-socket metric table reads with a
mutex
platform/x86/amd/hsmp: ACPI HSMP refcounted sockets and coordinated
release
platform/x86/amd/hsmp: Serialize the data plane against socket
teardown
drivers/platform/x86/amd/hsmp/acpi.c | 130 ++++++++++++++++++++++++---
drivers/platform/x86/amd/hsmp/hsmp.c | 118 +++++++++++++++++++++++-
drivers/platform/x86/amd/hsmp/hsmp.h | 16 +++-
drivers/platform/x86/amd/hsmp/plat.c | 42 ++++++++-
4 files changed, 286 insertions(+), 20 deletions(-)
base-commit: ff7836fa850c2f815bc219f1e48f6ec8699f4ae7
--
2.34.1
next reply other threads:[~2026-07-07 5:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 5:15 Muralidhara M K [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-07-06 14:21 Muralidhara M K
2026-07-06 14:26 ` M K, Muralidhara
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=20260707051534.3381387-1-muralidhara.mk@amd.com \
--to=muralidhara.mk@amd.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=muthusamy.ramalingam@amd.com \
--cc=platform-driver-x86@vger.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
all inboxes | Powered by JetHome®