mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "M K, Muralidhara" <muralimk@amd.com>
To: Muralidhara M K <muralidhara.mk@amd.com>, ilpo.jarvinen@linux.intel.com
Cc: platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org, muthusamy.ramalingam@amd.com
Subject: Re: [PATCH v6 0/6] platform/x86/amd/hsmp: Serialize the data plane against socket teardown
Date: Mon, 20 Jul 2026 21:02:40 +0530	[thread overview]
Message-ID: <7608d951-c2df-42e3-8738-9e83e6c8d408@amd.com> (raw)
In-Reply-To: <20260713044005.1194115-1-muralidhara.mk@amd.com>

Hi Ilpo,
Could you please review this series.

On 7/13/2026 10:09 AM, 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.
> 
> A single rw_semaphore, hsmp_sock_rwsem, serializes everything: the data
> plane takes it for read so messages run concurrently, 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 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 | 113 +++++++++++++++++++--
>   drivers/platform/x86/amd/hsmp/hsmp.h |  14 ++-
>   drivers/platform/x86/amd/hsmp/plat.c |  38 ++++++-
>   4 files changed, 288 insertions(+), 23 deletions(-)
> 
> 
> base-commit: ff7836fa850c2f815bc219f1e48f6ec8699f4ae7


      parent reply	other threads:[~2026-07-20 15:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-13  4:39 Muralidhara M K
2026-07-13  4:40 ` [PATCH v6 1/6] platform/x86/amd/hsmp: Serialize ACPI HSMP probe and remove with an rwsem Muralidhara M K
2026-07-13  4:40 ` [PATCH v6 2/6] platform/x86/amd/hsmp: Map the metric table with ioremap() and unmap it explicitly Muralidhara M K
2026-07-13  4:40 ` [PATCH v6 3/6] platform/x86/amd/hsmp: Serialize per-socket metric table reads with a mutex Muralidhara M K
2026-07-13  4:40 ` [PATCH v6 4/6] platform/x86/amd/hsmp: Clear mdev.this_device on deregister Muralidhara M K
2026-07-13  4:40 ` [PATCH v6 5/6] platform/x86/amd/hsmp: ACPI HSMP refcounted sockets and coordinated release Muralidhara M K
2026-07-13  4:40 ` [PATCH v6 6/6] platform/x86/amd/hsmp: Serialize the data plane against socket teardown Muralidhara M K
2026-07-22 13:11   ` Ilpo Järvinen
2026-07-23  5:32     ` M K, Muralidhara
2026-07-20 15:32 ` M K, Muralidhara [this message]

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=7608d951-c2df-42e3-8738-9e83e6c8d408@amd.com \
    --to=muralimk@amd.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=muralidhara.mk@amd.com \
    --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

Powered by JetHome