From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Muralidhara M K <muralidhara.mk@amd.com>
Cc: platform-driver-x86@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 0/6] platform/x86/amd/hsmp: Serialize the data plane against socket teardown
Date: Wed, 8 Jul 2026 13:07:00 +0300 (EEST) [thread overview]
Message-ID: <c0ff9acc-5a29-1556-dc35-3df205bcf9ec@linux.intel.com> (raw)
In-Reply-To: <20260708042405.3758294-1-muralidhara.mk@amd.com>
On Wed, 8 Jul 2026, Muralidhara M K wrote:
> This series makes the AMD HSMP driver safe against concurrent probe/remove
> of its per-socket devices and against the lock-free 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.
>
> The fix is built up in small, bisectable steps:
>
> 1. Serialize the ACPI probe/remove handshake with a dedicated mutex.
> 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 refcount and a single coordinated
> release helper, drop the is_probed flag and unparent /dev/hsmp.
> 6. Add hsmp_sock_rwsem: the data plane holds it for read, a teardown path
> holds it for write to drain in-flight messages before freeing the socket
> array or unmapping the mailbox.
>
> Each patch builds on its own and the series is checkpatch --strict clean.
>
> Changes since v3:
> - Use guard()/scoped locking consistently for both the probe mutex and the
> data-plane rwsem, from the first patch that introduces each lock.
> - Platform teardown now uses devm_add_action_or_reset(): the metric-table
> unmap and the per-socket mutex destroy run from a single devres action
> instead of explicit remove()/probe-failure code. The ACPI array is shared
> across per-socket devices and must outlive an individual unbind, so it
> stays on explicit teardown.
> - Split the mdev.this_device clear into its own patch (new patch 4).
> - Drop dead defensive checks: the !sock guard in hsmp_unmap_metric_tbls()
> and the if (sock) in hsmp_acpi_remove(). Keep and document the one in the
> probe-failure path, where sock can legitimately be NULL.
> - Replace the !--refs construct with a plain decrement-then-test.
> - Explain why the probe path uses a separate mutex rather than the rwsem
> write side: the probe path itself drives the data plane via hsmp_test(),
> which takes the rwsem for read, so holding it for write across probe
> would deadlock.
Hi,
Could we have xx_locked() variant function for hsmp_test() to use so the
recursive locking problem is avoided?
> - Comment cleanups: drop history and "patch N" references, drop
> parenthetical function asides, single space after periods.
>
> Muralidhara M K (6):
> 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: 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 | 135 ++++++++++++++++++++++++---
> drivers/platform/x86/amd/hsmp/hsmp.c | 107 ++++++++++++++++++++-
> drivers/platform/x86/amd/hsmp/hsmp.h | 15 ++-
> drivers/platform/x86/amd/hsmp/plat.c | 26 ++++++
> 4 files changed, 265 insertions(+), 18 deletions(-)
>
>
> base-commit: ff7836fa850c2f815bc219f1e48f6ec8699f4ae7
>
--
i.
next prev parent reply other threads:[~2026-07-08 10:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 4:23 [PATCH v4 0/6] platform/x86/amd/hsmp: Serialize the data plane against socket teardown Muralidhara M K
2026-07-08 4:24 ` [PATCH v4 1/6] platform/x86/amd/hsmp: Serialize ACPI HSMP is_probed with a probe mutex Muralidhara M K
2026-07-08 4:24 ` [PATCH v4 2/6] platform/x86/amd/hsmp: Map the metric table with ioremap() and unmap it explicitly Muralidhara M K
2026-07-08 10:17 ` Ilpo Järvinen
2026-07-09 5:40 ` M K, Muralidhara
2026-07-08 4:24 ` [PATCH v4 3/6] platform/x86/amd/hsmp: Serialize per-socket metric table reads with a mutex Muralidhara M K
2026-07-08 4:24 ` [PATCH v4 4/6] platform/x86/amd/hsmp: Clear mdev.this_device on deregister Muralidhara M K
2026-07-08 4:24 ` [PATCH v4 5/6] platform/x86/amd/hsmp: ACPI HSMP refcounted sockets and coordinated release Muralidhara M K
2026-07-08 4:24 ` [PATCH v4 6/6] platform/x86/amd/hsmp: Serialize the data plane against socket teardown Muralidhara M K
2026-07-08 10:07 ` Ilpo Järvinen [this message]
2026-07-09 5:33 ` [PATCH v4 0/6] " M K, Muralidhara
2026-07-09 9:15 ` Ilpo Järvinen
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=c0ff9acc-5a29-1556-dc35-3df205bcf9ec@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=muralidhara.mk@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 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.