wireguard-linux/drivers/platform/x86/amd/hsmp, branch stable

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00Z

This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook

platform/x86/amd/hsmp: Reject negative power cap writes in hwmon

2026-08-18T14:30:10Z

hsmp_hwmon_write() takes the user-supplied hwmon value as a signed long and assigns "val / MICROWATT_PER_MILLIWATT" to msg.args[0], which is a __u32. MICROWATT_PER_MILLIWATT is an unsigned long, so a negative write to power1_cap (e.g. "echo -1 > power1_cap") is first converted to a huge unsigned value by the division and then stored into the u32 argument. As a result a nonsensical, multi-gigawatt socket power limit is sent to the SMU via HSMP_SET_SOCKET_POWER_LIMIT instead of the write being rejected. Reject negative values with -EINVAL before the conversion. Tested with HSMP enabled: CAP=$(dirname $(grep -l amd_hsmp_hwmon \ /sys/class/hwmon/hwmon*/name | head -1))/power1_cap # negative write echo -1000000 > $CAP ; echo "ret=$?" # valid positive write must still work echo 400000000 > $CAP ; echo "ret=$?" Before: # echo -1000000 > $CAP ; echo "ret=$?" ret=0 <- accepted; bogus limit sent to SMU # echo 400000000 > $CAP ; echo "ret=$?" ret=0 After: # echo -1000000 > $CAP ; echo "ret=$?" bash: echo: write error: Invalid argument ret=1 <- rejected with -EINVAL # echo 400000000 > $CAP ; echo "ret=$?" ret=0 <- valid write still works Fixes: 92c025db52bb ("platform/x86/amd/hsmp: Report power via hwmon sensors") Signed-off-by: Hemanth Selam Link: https://patch.msgid.link/20260812090012.140193-1-hemanth.selam@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen

platform/x86/amd/hsmp: Enable protocol version 7 metric tables on the ACPI driver

2026-07-28T18:09:19Z

The ACPI driver currently prepares the per-socket metric table only on HSMP_PROTO_VER6. With protocol version 7 in use on Family 1Ah Model 50h-5Fh, userspace cannot reach the larger ~13 KB table: hsmp_get_tbl_dram_base() is skipped, sock->metric_tbl_addr stays NULL, and the ioctl added earlier in this series has nothing to read. Widen the proto_ver gate in init_acpi() from '== HSMP_PROTO_VER6' to '>= HSMP_PROTO_VER6' so the DRAM region is mapped and sock->metric_tbl_size is populated on protocol version 7 (and any future compatible version), making the ioctl path functional. hsmp_metric_tbl_acpi_read() now returns -EOPNOTSUPP whenever the running protocol version is not VER6, because the sysfs binary attribute cannot carry a table larger than PAGE_SIZE. Version 7 userspace gets a clear, actionable error and a documented pointer to HSMP_IOCTL_GET_TELEMETRY_DATA; version 6 userspace sees no change. The non-ACPI plat.c path is intentionally left untouched: it covers Family 1Ah Model 0h-Fh hardware fixed at protocol version 6, where the existing metrics_bin remains the supported interface. Co-developed-by: Muthusamy Ramalingam Signed-off-by: Muthusamy Ramalingam Signed-off-by: Muralidhara M K Link: https://patch.msgid.link/20260727141542.3370108-6-muralidhara.mk@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen

platform/x86/amd/hsmp: Add IOCTL_GET_TELEMETRY_DATA for metric table reads

2026-07-28T18:09:17Z

The metric table needs to be delivered to userspace as a single atomic snapshot, but the current sysfs metrics_bin path is a file read: userspace can read it in chunks and observe a torn snapshot if an SMU refresh happens between read() calls. The same path is also bounded by PAGE_SIZE, so the ~13 KB table used by HSMP protocol version 7 on Family 1Ah Model 50h-5Fh cannot be returned at all, regardless of how userspace reads it. Rather than extend sysfs to lift both restrictions, expose the metric table through the existing HSMP character device using a new ioctl that always copies the table in one shot. Add struct hsmp_telemetry_data and HSMP_IOCTL_GET_TELEMETRY_DATA to the UAPI header. Under the surrounding #pragma pack(4), placing the __u64 user pointer first gives a tight 16-byte layout that is identical for 32- and 64-bit callers, and the trailing __u16 reserved field is rejected with -EINVAL if non-zero so future kernels can repurpose it without breaking already-deployed userspace. The command is encoded with _IOW because the kernel only reads the request struct; the snapshot travels through the user pointer it carries. The requested size may be anything from one byte up to the size firmware reported for that socket's table. A short request returns the leading bytes of the snapshot, so userspace built against an older table layout keeps working on firmware that grew the table, mirroring the relaxed response_sz rule applied to HSMP messages earlier in this series. A request larger than the firmware table is rejected with -EINVAL rather than short-written, so a caller can never mistake a partial copy for a full one. Dispatch hsmp_ioctl() on the ioctl command: the existing message handler is factored out as hsmp_ioctl_msg() for HSMP_IOCTL_CMD, and HSMP_IOCTL_GET_TELEMETRY_DATA goes to a new hsmp_ioctl_get_telemetry() helper. /dev/hsmp is a singleton character device that outlives an individual socket unbind, so an ioctl issued on an already-open fd can run concurrently with socket teardown. hsmp_sock_rwsem is the driver's contract for that: the data plane takes it for read, and probe and remove take it for write to drain the data plane before freeing the socket array, unmapping the metric tables and destroying the per-socket mutexes. hsmp_ioctl_get_telemetry() takes it for read across the socket lookup, the checks on that socket's metric-table state and the table read itself, so none of that state can be torn down underneath it. Without this the handler would sleep in its kvmalloc() holding no lock at all, and could resume with a freed socket, locking a destroyed mutex and reading from an unmapped iomem region. The lock is dropped before the copy_to_user(), because faulting in the destination can block indefinitely on a userfaultfd-backed buffer and would otherwise leave a socket unbind waiting for the write lock. Since hsmp_metric_tbl_read() reached the mailbox through hsmp_send_message(), which takes hsmp_sock_rwsem itself, calling it with the lock already held would recursively take the read side and can deadlock against a queued writer. Split out hsmp_metric_tbl_read_locked(), which asserts the lock and uses hsmp_send_message_locked(), and leave hsmp_metric_tbl_read() as a wrapper that takes the read lock for the sysfs callers. This also brings the whole fill-and-copy under the rwsem for those callers, where the memcpy_fromio() previously ran outside it, and makes the lock order uniformly hsmp_sock_rwsem -> metric_read_lock -> hsmp_sem. The user-controlled socket index in HSMP_IOCTL_GET_TELEMETRY_DATA is clamped with array_index_nospec() before indexing hsmp_pdev.sock[], mitigating Spectre v1 (CVE-2017-5753). Include linux/nospec.h, which the file relied on getting transitively. Co-developed-by: Muthusamy Ramalingam Signed-off-by: Muthusamy Ramalingam Signed-off-by: Muralidhara M K Link: https://patch.msgid.link/20260727141542.3370108-5-muralidhara.mk@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen

platform/x86/amd/hsmp: Source metric-table size from firmware

2026-07-28T18:09:16Z

The driver hard-codes the metric-table region size to sizeof(struct hsmp_metric_table). That is correct for HSMP protocol version 6 but mis-sizes the ioremap of the SMU DRAM region on newer platforms: Family 1Ah Model 50h-5Fh exposes a ~13 KB table under protocol version 7, and the table is expected to keep growing on future firmware. The same hard-coded value also forces hsmp_metric_tbl_read() to reject any read that follows the actual firmware layout. Pick up the table size from firmware instead. SMU on Family 1Ah Model 50h and later populates HSMP_GET_METRIC_TABLE_DRAM_ADDR's args[2] with the DRAM region size in bytes; older firmware leaves it 0. Bump the descriptor's response_sz to 3 so the field is read, and store the result in the new per-socket hsmp_socket.metric_tbl_size, which is then used both for the ioremap() of the region and as the expected size in hsmp_metric_tbl_read(). The size is stored per socket rather than per platform because hsmp_get_tbl_dram_base() runs once per socket and each socket maps its own region. A single platform-wide field would let the last socket's size be used to copy out of an earlier socket's smaller mapping. Bump DRIVER_VERSION to 2.6. Behaviour on existing protocol-version-6 hardware is unchanged. Reading a third response word is safe there: for this command SMU leaves args[2] as 0 rather than a stale value from an earlier mailbox transaction, so the fallback always applies, yielding the same value as the previous hard-coded one, and both the ioremap and the size check produce the same result as before. Co-developed-by: Muthusamy Ramalingam Signed-off-by: Muthusamy Ramalingam Signed-off-by: Muralidhara M K Link: https://patch.msgid.link/20260727141542.3370108-4-muralidhara.mk@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen

platform/x86/amd/hsmp: Unify response_sz validation to an upper-bound check

2026-07-28T18:09:13Z

As HSMP protocol versions evolve, existing message IDs sometimes gain additional response words on newer firmware. validate_message() currently enforces a strict equality (response_sz == table value) for HSMP_SET and HSMP_GET, so userspace compiled against an earlier descriptor table is rejected with -EINVAL when it asks for fewer response words than the in-kernel table now declares - even though that caller has no interest in the additional words. Only HSMP_SET_GET already used a relaxed upper-bound check. Replace the per-type branching with a single upper-bound check for all message types. Userspace can now request fewer response words than hardware provides, while requests that exceed the descriptor table (and therefore the hardware capability) are still rejected. Co-developed-by: Muthusamy Ramalingam Signed-off-by: Muthusamy Ramalingam Signed-off-by: Muralidhara M K Link: https://patch.msgid.link/20260727141542.3370108-3-muralidhara.mk@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen

platform/x86/amd/hsmp: Serialize the data plane against socket teardown

2026-07-24T16:12:22Z

Before this change the HSMP data plane runs without any coordination with driver teardown: open /dev/hsmp fds and hwmon sysfs reads call hsmp_send_message() while probe and remove bring sockets up and down. misc_deregister() does not drain already-open fds, so an in-flight message can race a concurrent unbind and touch a freed socket array or an unmapped mailbox. Add the read side of hsmp_sock_rwsem to the data plane. Split the message send into hsmp_send_message_locked(), which does the bounds check and MMIO access and asserts the rwsem is held, and hsmp_send_message(), which wraps it in guard(rwsem_read). Probe and remove hold the rwsem for write, so they drain in-flight messages and keep new ones out while they tear a socket down. The probe-time senders run under the probe write lock and so must not take the rwsem again: route hsmp_test(), hsmp_cache_proto_ver() and hsmp_get_tbl_dram_base() through hsmp_send_message_locked() to avoid recursive locking. A single rwsem therefore covers both the data plane and the probe/remove handshake, with no separate probe lock: - acpi.c already holds it for write across probe for the socket-array and misc-registration handshake, so the mailbox handshake now nests under that same lock. - plat.c takes it for write around init_platform_device(). It is not held across devm_add_action_or_reset() so the release action, which also takes it for write, cannot deadlock if that registration fails. Signed-off-by: Muralidhara M K Link: https://patch.msgid.link/20260723094656.3806028-7-muralidhara.mk@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen

platform/x86/amd/hsmp: ACPI HSMP refcounted sockets and coordinated release

2026-07-24T16:12:18Z

The ACPI driver binds one platform device per socket but shares a single socket array and a single /dev/hsmp misc device across them. Replace the is_probed flag with state that tracks this shared ownership: - miscdevice.this_device tells whether /dev/hsmp is registered, so the misc device is registered on the first socket and torn down last. A preceding change clears mdev.this_device on deregister so this gate stays reliable across a re-probe. - a kref tracks the sockets that share the array. The first probe initializes it, each further probe takes a reference and every remove (or probe failure) drops one; the last put runs the release callback. All get/put happen under hsmp_sock_rwsem held for write, so the counting is already serialized and kref's atomic is not strictly needed, but kref gives the clearer get/put interface and a release callback. The shared socket array is allocated with kcalloc() on the first probe and freed by the release callback once the last reference is dropped. hsmp_acpi_sock_release() is the single teardown helper, run from kref_put(): it deregisters /dev/hsmp if registered, unmaps any metric-table DRAM, destroys the per-socket mutexes and frees the array. The remove path and the probe-failure path both reach it through the last put, so the teardown lives in one place. Both paths also clear this socket's dev, so a message issued after a non-final unbind (or to a socket that failed to probe on a multi-socket system, whose array stays alive and whose remove() is never called) cannot reach the mailbox that devres is about to unmap. Two lifetime fixes fall out of the array persisting across a non-final unbind: - hsmp_get_tbl_dram_base() iounmap()s any stale metric_tbl_addr before remapping, so a rebind does not leak one mapping per cycle. It runs during (re)probe before the metric sysfs attribute is exposed, so no reader can be using the old mapping. - The ACPI path registers /dev/hsmp unparented by passing NULL to hsmp_misc_register(). Its per-socket devices can be unbound individually and out of order and the misc device outlives all but the last of them, so parenting it to one socket's device would leave a dangling parent. hsmp_misc_register() now takes the parent from its caller, so the platform driver keeps parenting /dev/hsmp to its single device. hsmp_sock_rwsem is held for write across probe and remove, so the release and probe-failure cleanup run with it already held; an upcoming change adds its read side so the same lock also drains the data plane. Signed-off-by: Muralidhara M K Link: https://patch.msgid.link/20260723094656.3806028-6-muralidhara.mk@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen

platform/x86/amd/hsmp: Clear mdev.this_device on deregister

2026-07-24T16:12:16Z

misc_deregister() destroys the device but leaves miscdevice.this_device pointing at the freed struct device. Clear it so any later check of this_device, and a subsequent re-register, does not observe a stale pointer. An upcoming change uses this_device to track whether /dev/hsmp is registered across the shared ACPI sockets and relies on it being NULL after deregister. Signed-off-by: Muralidhara M K Link: https://patch.msgid.link/20260723094656.3806028-5-muralidhara.mk@amd.com Signed-off-by: Ilpo Järvinen

platform/x86/amd/hsmp: Serialize per-socket metric table reads with a mutex

2026-07-24T16:12:14Z

HSMP_GET_METRIC_TABLE makes the firmware refill a shared per-socket metric DRAM region, which hsmp_metric_tbl_read() then copies out with memcpy_fromio(). Two concurrent readers of the metrics_bin sysfs attribute on the same socket can race: one can trigger a fresh fill while the other is mid-copy and return a torn snapshot. (The hwmon path does not touch this region; it only issues power messages via hsmp_send_message().) Embed a struct mutex metric_read_lock in each hsmp_socket and hold it across the fill-and-copy in hsmp_metric_tbl_read(). Add hsmp_init_metric_read_locks() and hsmp_destroy_metric_read_locks(), which take only struct hsmp_plat_device and iterate pdev->sock[] over pdev->num_sockets so the caller cannot pass a count that disagrees with the array. Wire them into both front-ends' probe and teardown paths so the mutex is always initialized before metrics_bin is exposed: the platform driver and the ACPI driver both drive hsmp_metric_tbl_read() through the same 0444 metrics_bin attribute. Doing this in one patch avoids a bisection point where an ACPI read would lock an uninitialized mutex. Signed-off-by: Muralidhara M K Link: https://patch.msgid.link/20260723094656.3806028-4-muralidhara.mk@amd.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen