[PATCH v7 0/6] platform/x86/amd/hsmp: Serialize the data plane against socket teardown

Muralidhara M K posted 6 patches 1 day, 11 hours ago
drivers/platform/x86/amd/hsmp/acpi.c | 146 +++++++++++++++++++++++++++++++----
drivers/platform/x86/amd/hsmp/hsmp.c | 112 +++++++++++++++++++++++++--
drivers/platform/x86/amd/hsmp/hsmp.h |  14 +++-
drivers/platform/x86/amd/hsmp/plat.c |  38 ++++++++-
4 files changed, 287 insertions(+), 23 deletions(-)
[PATCH v7 0/6] platform/x86/amd/hsmp: Serialize the data plane against socket teardown
Posted by Muralidhara M K 1 day, 11 hours ago
This series makes the AMD HSMP driver safe against concurrent probe/remove
of its per-socket devices and against the data plane (open /dev/hsmp fds and
hwmon/sysfs reads) racing socket teardown.

The ACPI front-end binds one platform device per socket but shares a single
socket array and a single /dev/hsmp misc device across them, while the data
plane issues mailbox messages with no coordination with driver teardown.
misc_deregister() does not drain already-open fds, so an in-flight message
can touch a freed socket array or an unmapped mailbox on unbind.

A single rw_semaphore, hsmp_sock_rwsem, serializes everything: the data
plane takes it for read so messages run concurrently with each other, and
probe and remove take it for write to bring sockets up and tear them down
while excluding and draining the data plane. The fix is built up in small,
bisectable steps:

 1. Introduce hsmp_sock_rwsem and hold it for write across ACPI probe/remove
    so concurrent per-socket probes cannot race the bring-up handshake or
    the one-time socket-array allocation.
 2. Map the metric table with ioremap() and release it via a devres action,
    so its lifetime is no longer pinned to a single per-socket devres scope.
 3. Serialize the per-socket metric-table fill-and-copy with a mutex.
 4. Clear mdev.this_device on deregister (independent hygiene fix that the
    next patch relies on to track /dev/hsmp registration).
 5. Track shared socket ownership with a kref and a single coordinated
    release helper, drop the is_probed flag and unparent /dev/hsmp on the
    ACPI path.
 6. Add the read side of hsmp_sock_rwsem to the data plane: split the send
    into hsmp_send_message_locked() (asserts the rwsem is held) and
    hsmp_send_message() (wraps it in guard(rwsem_read)). Route the probe-only
    senders through the locked variant so probe, holding the write lock, does
    not recurse on the rwsem.

Each patch builds on its own and the series is checkpatch --strict clean.

Changes since v6:
 - Comment-only fixes addressing review feedback on patch 6: the code
   comments no longer describe the data plane as "lock-free". After this
   series hsmp_send_message() takes hsmp_sock_rwsem for read, so the data
   plane is gated by a lock (the read side simply does not exclude other
   readers); calling it lock-free contradicted the rwsem documentation and
   was misleading. Reworded hsmp_send_message() (patch 6, hsmp.c) and the
   kref-release / probe / remove teardown comments (patch 5, acpi.c), and
   dropped the "lock-free" wording from the patch 1 and patch 6 changelogs.
   No functional change.

Changes since v5:
 - Track the shared ACPI sockets with a kref instead of a hand-rolled
   unsigned int counter (patch 5), as suggested on v5. The first probe
   kref_init()s it, each further probe kref_get()s and every remove or
   probe failure kref_put()s; the last put runs hsmp_acpi_sock_release() as
   the kref release callback. get/put still happen under hsmp_sock_rwsem
   held for write, so the atomic is not strictly needed, but kref gives the
   clearer interface.
 - Keep the rwsem read side for the data plane rather than switching it to
   kref_get_unless_zero(). The kref tracks the shared socket array, but each
   socket's mailbox is a per-device devm_ioremap_uc() mapping that devres
   unmaps on that socket's individual (non-final) unbind while the array and
   the kref are still alive. An array-level kref would keep the array from
   being freed but would not stop that per-socket mailbox unmap, so the read
   side is what serializes the sock->dev gate and the MMIO access against a
   concurrent per-socket teardown. A kref_get_unless_zero() data plane would
   need a per-socket reference tied to each mailbox's lifetime, a larger
   redesign; noted for a possible follow-up.

Muralidhara M K (6):
  platform/x86/amd/hsmp: Serialize ACPI HSMP probe and remove with an
    rwsem
  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: Clear mdev.this_device on deregister
  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 | 146 +++++++++++++++++++++++++++++++----
 drivers/platform/x86/amd/hsmp/hsmp.c | 112 +++++++++++++++++++++++++--
 drivers/platform/x86/amd/hsmp/hsmp.h |  14 +++-
 drivers/platform/x86/amd/hsmp/plat.c |  38 ++++++++-
 4 files changed, 287 insertions(+), 23 deletions(-)


base-commit: ff7836fa850c2f815bc219f1e48f6ec8699f4ae7
-- 
2.34.1
Re: [PATCH v7 0/6] platform/x86/amd/hsmp: Serialize the data plane against socket teardown
Posted by Ilpo Järvinen 5 hours ago
On Thu, 23 Jul 2026 15:16:50 +0530, Muralidhara M K wrote:

> This series makes the AMD HSMP driver safe against concurrent probe/remove
> of its per-socket devices and against the data plane (open /dev/hsmp fds and
> hwmon/sysfs reads) racing socket teardown.
> 
> The ACPI front-end binds one platform device per socket but shares a single
> socket array and a single /dev/hsmp misc device across them, while the data
> plane issues mailbox messages with no coordination with driver teardown.
> misc_deregister() does not drain already-open fds, so an in-flight message
> can touch a freed socket array or an unmapped mailbox on unbind.
> 
> [...]

Thank you for your contribution, it has been applied to my local
review-ilpo-next branch. Note it will show up in the public
platform-drivers-x86/review-ilpo-next branch only once I've pushed my
local branch there, which might take a while.

FYI [if applicable to your patch], as per Linus' policy change, also
fixes are mostly routed through for-next unless the fix is for a
commit introduced in the most recent cycle or is clearly a regression
fix.

The list of commits applied:
[1/6] platform/x86/amd/hsmp: Serialize ACPI HSMP probe and remove with an rwsem
      commit: 9c40a57258f6cb4109de46467966498e6f90ece6
[2/6] platform/x86/amd/hsmp: Map the metric table with ioremap() and unmap it explicitly
      commit: 5622564fc6924c1607944f0ad22be81ed6fd38fb
[3/6] platform/x86/amd/hsmp: Serialize per-socket metric table reads with a mutex
      commit: 8da4fedd5d1147d26e6ddbd7be2f1f5519df37dd
[4/6] platform/x86/amd/hsmp: Clear mdev.this_device on deregister
      commit: 6bd243d5abd91ee7d7fa58a9ed60381da49b4b0a
[5/6] platform/x86/amd/hsmp: ACPI HSMP refcounted sockets and coordinated release
      commit: 9b2895edb2b3ec1fb8a5adadb5305f6459151d38
[6/6] platform/x86/amd/hsmp: Serialize the data plane against socket teardown
      commit: c7acedb2db001160b1ec41cdcc759dd664150666

--
 i.