summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-05-18openvswitch: vport: fix race between linking and the device notifierIlya Maximets
Sashiko reports that it is technically possible that we got the device reference, but by the time we're linking it to the OVS datapath, it may be already in the process of being deleted. In this case if the notifier wins the race for RTNL, it will see that the device is not yet in the OVS datapath (ovs_netdev_get_vport() will fail in the dp_device_event()) and will do nothing. Then the ovs_netdev_link() will take the RTNL and link the unregistering device to OVS datapath. Eventually, netdev_wait_allrefs_any() will re-broadcast the event and the device will be properly detached, but it will take at least a second before that happens, so it's not something we should rely on. Let's avoid linking the non-registered device in the first place. Note: As per documentation, RTNL doesn't protect the reg_state, but it actually does for all the state transitions we care about here, so it should not be necessary to use READ_ONCE or taking the instance lock. We can still do that, but we have a few more places even in this file where the reg_state is accessed without those while under RTNL, and many more places like this across the kernel code, so it might make more sense to change all of them in a more centralized fashion in the future, if necessary. Fixes: ccb1352e76cf ("net: Add Open vSwitch kernel components.") Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Reviewed-by: Aaron Conole <aconole@redhat.com> Acked-by: Eelco Chaudron <echaudro@redhat.com> Link: https://patch.msgid.link/20260514184702.2461435-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink()Weiming Shi
rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: <TASK> __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) </TASK> Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers. Fixes: ceed73a2cf4a ("drivers: net: ethernet: qualcomm: rmnet: Initial implementation") Reported-by: Xiang Mei <xmei5@asu.edu> Signed-off-by: Weiming Shi <bestswngs@gmail.com> Link: https://patch.msgid.link/20260514122511.3083479-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18net: appletalk: fix NULL pointer dereference in aarp_send_ddp()Weiming Shi
aarp_send_ddp() calls atalk_find_dev_addr(dev) in the LocalTalk fast path without checking for NULL. When the device has no AppleTalk interface configured (dev->atalk_ptr == NULL), this leads to a NULL pointer dereference at the at->s_net access. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:aarp_send_ddp (net/appletalk/aarp.c:552 (discriminator 2)) Call Trace: <TASK> atalk_sendmsg (net/appletalk/ddp.c:1715) __sys_sendto (net/socket.c:2265 (discriminator 1)) __x64_sys_sendto (net/socket.c:2272) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Add a NULL check consistent with the other callers of atalk_find_dev_addr(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Xiang Mei <xmei5@asu.edu> Signed-off-by: Weiming Shi <bestswngs@gmail.com> Link: https://patch.msgid.link/20260514123806.3085961-3-bestswngs@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18netdevsim: psp: reset spi on key rotation and check for exhaustion on allocDaniel Zahka
The PSP spec states that the lower 31b of the SPI need to be non-zero. Though not in the spec, I think it is reasonable to reset the lower 31b of the spi space after a key rotation, and to also decline to generate session keys when the lower 31b saturate. Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260515-spi-handle-v1-1-debf8cb467cb@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18Merge branch 'net-mlx5-frag-buffer-improvements'Jakub Kicinski
Tariq Toukan says: ==================== net/mlx5: frag buffer improvements This series adds observability for mlx5 fragment buffer DMA pools and improves the default NUMA placement policy for fragment buffer allocations. Patch 1 adds a debugfs interface exposing per-node DMA pool usage statistics for mlx5_frag_buf allocations, helping with debugging and visibility into pool utilization. Patch 2 improves locality of default fragment buffer allocations by using numa_mem_id() when no explicit NUMA node is requested, allowing allocations to prefer the current CPU's local memory node. Together, these changes improve both introspection and memory locality behavior of mlx5 fragment buffer allocations. ==================== Link: https://patch.msgid.link/20260514104925.337570-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18net/mlx5: add debugfs stats for frag buf dma poolsNimrod Oren
Add a debugfs file exposing per-node DMA pool usage for mlx5_frag_buf allocations. # cat /sys/kernel/debug/mlx5/<dev>/frag_buf_dma_pools node block_size used_blocks allocated_blocks 0 4096 0 0 0 8192 0 0 0 16384 0 0 0 32768 0 0 0 65536 0 0 1 4096 0 0 1 8192 0 0 1 16384 0 0 1 32768 0 0 1 65536 0 0 Signed-off-by: Nimrod Oren <noren@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260514104925.337570-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18net/mlx5: use numa_mem_id() for default frag buf allocationsNimrod Oren
Use the current CPU's local memory node when callers do not request a specific NUMA node for mlx5_frag_buf allocations. Signed-off-by: Nimrod Oren <noren@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260514104925.337570-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18net/mlx5e: xsk: Fix unlocked writing to ICOSQDragos Tatulea
During napi poll, when the affinity changes and there's still XSK work to be done, we trigger an ICOSQ interrupt on the new CPU. However, this triggering on the ICOSQ is done unprotected. There are 2 such races: A) mlx5e_trigger_irq() is called while mlx5e_xsk_alloc_rx_mpwqe() is running from a different CPU due to affinity change. This can happen because IRQ triggering is done after napi_complete_done(). At this point the NAPI can be scheduled on a different CPU. Like this: CPU A (old affinity, NAPI tail) CPU B (new affinity, fresh NAPI) ------------------------------- -------------------------------- napi_complete_done() clears SCHED mlx5e_cq_arm(...) napi_schedule_prep() sets SCHED mlx5e_napi_poll() mlx5e_xsk_alloc_rx_mpwqe() mlx5e_icosq_sync_lock() // noop memcpy 640 B UMR body advance sq->pc by 10 mlx5e_trigger_irq(&c->icosq) wqe_info[pi] = {NOP, 1} mlx5e_post_nop() advances sq->pc B) mlx5e_trigger_irq() is called on the ICOSQ when mlx5e_trigger_napi_icosq() is running. The obvious fix would be to lock the ICOSQ. But ICOSQ has an optimized locking scheme that doesn't work for this scenario. Kick the async ICOSQ instead which is always locked. This issue was noticed in the wild with the following splat: netdevice: ge-0-0-1: Bad OP in ICOSQ CQE: 0xd WARNING: drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:826 [...] [...] Call Trace: <IRQ> mlx5e_napi_poll+0x11d/0x7f0 [mlx5_core] __napi_poll+0x30/0x200 ? skb_defer_free_flush+0x9c/0xc0 net_rx_action+0x2fe/0x3f0 handle_softirqs+0xd8/0x340 __irq_exit_rcu+0xbc/0xe0 common_interrupt+0x85/0xa0 </IRQ> <TASK> asm_common_interrupt+0x26/0x40 [...] ---[ end trace 0000000000000000 ]--- mlx5_core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2022, qn 0x8f4, opcode 0xd, syndrome 0x2, vendor syndrome 0x68 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000030: 00 00 00 00 01 00 68 02 01 00 08 f4 de 14 59 d2 WQE DUMP: WQ size 16384 WQ cur size 0, WQE index 0x1e14, len: 64 00000000: 00 00 00 01 d9 ed 80 02 00 00 00 01 d9 ed 90 02 00000010: 00 00 00 01 d9 ed a0 02 00 00 00 01 d9 ed b0 02 00000020: 00 00 00 01 d9 ed c0 02 00 00 00 01 d9 ed d0 02 00000030: 00 00 00 01 d9 ed e0 02 00 00 00 01 d9 ed f0 02 mlx5_core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2023, qn 0x8f4, opcode 0xd, syndrome 0x5, vendor syndrome 0xf9 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000030: 00 00 00 00 01 00 f9 05 01 00 08 f4 de 15 cf d2 Fixes: db05815b36cb ("net/mlx5e: Add XSK zero-copy support") Reported-by: Paul Saab <ps@mu.org> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260513064613.334602-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18PCI: imx6: Parse 'reset-gpios' in Root Port nodesSherry Sun
The current DT binding for pci-imx6 specifies the 'reset-gpios' property in the host bridge node. However, the PERST# signal logically belongs to individual Root Ports rather than the host bridge itself. This becomes important when supporting PCIe Key E connector and the PCI power control framework for pci-imx6 driver, which requires properties to be specified in Root Port nodes. Parse 'reset-gpios' from Root Port nodes and the PCIe bridge nodes under the Root Port using the common helper pci_host_common_parse_ports(), and update the reset GPIO handling to use the parsed port list from bridge->ports. To maintain DT backwards compatibility, fall back to the legacy method of parsing the host bridge node if the reset property is not present in the Root Port nodes. Since now the reset GPIO is obtained with GPIOD_ASIS flag, it may be in input mode, so use gpiod_direction_output() instead of gpiod_set_value_cansleep() to ensure the reset GPIO is properly configured as output before setting its value. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Richard Zhu <hongxing.zhu@nxp.com> Link: https://patch.msgid.link/20260422093549.407022-5-sherry.sun@nxp.com
2026-05-18accel/amdxdna: Add expandable device heap supportLizhi Hou
Introduce an expandable device heap to avoid allocating a large heap upfront. Start with a smaller initial heap and grow it on demand. Return -EAGAIN when BO allocation fails due to insufficient heap space, allowing userspace to trigger heap expansion via a heap BO creation IOCTL and retry the allocation. Manage heap chunks using an xarray. On expansion, register new chunks with the firmware via MSG_OP_ADD_HOST_BUFFER. Since heap shrinking is not supported by the firmware, release all heap chunks on device close. Co-developed-by: Wendy Liang <wendy.liang@amd.com> Signed-off-by: Wendy Liang <wendy.liang@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260515161922.744647-1-lizhi.hou@amd.com
2026-05-18PCI: imx6: Assert PERST# before enabling regulatorsSherry Sun
The PCIe endpoint may start responding or driving signals as soon as its supply is enabled, even before the reference clock is stable. Asserting PERST# before enabling the regulator ensures that the endpoint remains in reset throughout the entire power-up sequence, until both power and refclk are known to be stable and link initialization can safely begin. Currently, the driver enables the vpcie3v3aux regulator in imx_pcie_probe() before PERST# is asserted in imx_pcie_host_init(), which may cause PCIe endpoint undefined behavior during early power-up. However, there is no issue so far because PERST# is requested as GPIOD_OUT_HIGH in imx_pcie_probe(), which guarantees that PERST# is asserted before enabling the vpcie3v3aux regulator. This prepares for an upcoming changes that will parse the reset property using the new Root Port binding, which will use GPIOD_ASIS when requesting the reset GPIO. With GPIOD_ASIS, the GPIO state is not guaranteed, so explicit sequencing is required. Fix the power sequencing by: 1. Moving vpcie3v3aux regulator enable from probe to imx_pcie_host_init(), where it can be properly sequenced with PERST#. 2. Moving imx_pcie_assert_perst() before regulator and clock enable to ensure correct ordering. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Richard Zhu <hongxing.zhu@nxp.com> Link: https://patch.msgid.link/20260422093549.407022-4-sherry.sun@nxp.com
2026-05-18PCI: host-generic: Add common helpers for parsing Root Port propertiesSherry Sun
Introduce generic helper functions to parse Root Port device tree nodes and extract common properties like reset GPIOs. This allows multiple PCI host controller drivers to share the same parsing logic. Define struct pci_host_port to hold common Root Port properties (currently only list of PERST# GPIO descriptors) and add pci_host_common_parse_ports() to parse Root Port nodes from device tree. Also add the 'ports' list to struct pci_host_bridge to better maintain parsed Root Port information. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260422093549.407022-3-sherry.sun@nxp.com
2026-05-18drm/v3d: Release indirect CSD GEM reference on CPU job freeMaíra Canal
v3d_get_cpu_indirect_csd_params() takes a reference to the indirect BO via drm_gem_object_lookup() and stashes it in cpu_job->indirect_csd.indirect, but nothing on the CPU job teardown path ever drops that reference. Drop the extra reference in v3d_cpu_job_free(). The NULL check covers ioctl errors before the lookup ran and CPU job types other than V3D_CPU_JOB_TYPE_INDIRECT_CSD, which leave the field zero-initialised. Cc: stable@vger.kernel.org Fixes: 18b8413b25b7 ("drm/v3d: Create a CPU job extension for a indirect CSD job") Assisted-by: Claude:claude-opus-4.7 Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260515-v3d-cpu-job-leaks-v1-2-7f147cbbf935@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-05-18drm/v3d: Fix use-after-free of CPU job query arrays on error pathMaíra Canal
The CPU job ioctl's fail label calls kvfree() on cpu_job's timestamp and performance query arrays after v3d_job_cleanup(), which drops the job's last reference and frees cpu_job. Reading cpu_job at that point is a use-after-free. Also, on the early v3d_job_init() failure path, it is a NULL dereference, since v3d_job_deallocate() zeroes the local pointer. In the success path, the arrays are released from the scheduler's .free_job callback, but on the error path, they are freed manually, as the job was never pushed to the scheduler. While the success path deals with this correctly, the fail path doesn't. On top of that, the manual kvfree() calls only free the array storage; they don't drm_syncobj_put() the per-query syncobjs that v3d_timestamp_query_info_free() and v3d_performance_query_info_free() release on the success path. So the same fail path that triggers the use-after-free also leaks one syncobj reference per query. Unify the CPU job teardown into the CPU job's kref destructor, mirroring v3d_render_job_free(). The scheduler's .free_job slot reverts to the generic v3d_sched_job_free() and the fail label drops the manual kvfree() calls, leaving a single teardown path that is reached from both the scheduler and the ioctl error path. That removes the use-after-free, the NULL dereference, and the syncobj leak by construction. Cc: stable@vger.kernel.org Fixes: 9ba0ff3e083f ("drm/v3d: Create a CPU job extension for the timestamp query job") Assisted-by: Claude:claude-opus-4.7 Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260515-v3d-cpu-job-leaks-v1-1-7f147cbbf935@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-05-18dt-bindings: PCI: fsl,imx6q-pcie: Add reset GPIO in Root Port nodeSherry Sun
Update fsl,imx6q-pcie.yaml to include the standard reset-gpios property for the Root Port node. The reset-gpios property is already defined in pci-bus-common.yaml for PERST#, so use it instead of the local reset-gpio property. Keep the existing reset-gpio property in the bridge node for backward compatibility, but mark it as deprecated. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260422093549.407022-2-sherry.sun@nxp.com
2026-05-18PCI: imx6: Fix IMX6SX_GPR12_PCIE_TEST_POWERDOWN handlingRichard Zhu
The IMX6SX_GPR12_PCIE_TEST_POWERDOWN bit does not control the PCIe reference clock on i.MX6SX. Instead, it is part of i.MX6SX PCIe core reset sequence. Move the IMX6SX_GPR12_PCIE_TEST_POWERDOWN assertion/deassertion into the core reset functions to properly reflect its purpose. Remove the .enable_ref_clk() callback for i.MX6SX since it was incorrectly manipulating this bit. Fixes: e3c06cd063d6 ("PCI: imx6: Add initial imx6sx support") Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260319090844.444987-1-hongxing.zhu@nxp.com
2026-05-18PCI/pwrctrl: Lock device when calling device_is_bound()Bartosz Golaszewski
The kerneldoc for device_is_bound() states that it must be called with the device lock taken. Synchronize the two calls in pwrctrl core. Fixes: b35cf3b6aa1e ("PCI/pwrctrl: Add APIs to power on/off pwrctrl devices") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260518100700.47581-1-bartosz.golaszewski@oss.qualcomm.com
2026-05-18PCI: Drop unnecessary retries when restoring BARsLukas Wunner
In 2012, commit 26f41062f28d ("PCI: check for pci bar restore completion and retry") amended pci_restore_state() to attempt BAR restoration up to 10 times. This was necessary because back in the day, only a 100 msec delay was observed after pcie_flr() carried out a Function Level Reset. The retries ensured that BARs were restored even if devices needed more time to come out of reset. In 2016, commit 5adecf817dd6 ("PCI: Wait for up to 1000ms after FLR reset") extended the delay to 1 sec. Commit a2758b6b8fdb ("PCI: Rename pci_flr_wait() to pci_dev_wait() and make it generic") subsequently extended it further to 60 sec. The lengthened delay makes it unnecessary to retry BAR restoration, so drop it. Reported-by: Bjorn Helgaas <bhelgaas@google.com> Closes: https://lore.kernel.org/r/20260416225745.GA41850@bhelgaas/ Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/785c98b50a7a00d0698848c75d51b8f5669ad18f.1777814679.git.lukas@wunner.de
2026-05-18PCI: Wait for device readiness after D3hot -> D0uninitialized transitionBjorn Helgaas
For a device that advertises No_Soft_Reset == 0, a transition from D3hot to D0uninitialized is a soft reset, and the resulting internal device state is undefined. Per PCIe r7.0, sec 2.3.1, a transition from D3hot to D0uninitialized mandates a minimum 10 ms delay before accessing the device. Following this delay, the device is permitted to respond to initial configuration requests with a Request Retry Status (RRS) completion status if it needs more time to initialize. Call pci_dev_wait() after pci_power_up() performs a D3hot->D0uninitialized transition to ensure the device is ready to accept config accesses, as is done after the similar transition in pci_pm_reset(). If the device is already ready, this is essentially a no-op except for one additional config read. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Link: https://patch.msgid.link/20260518191220.636213-3-bhelgaas@google.com
2026-05-18PCI: Log device readiness timeouts as errorsBjorn Helgaas
pci_dev_wait() waits for a device to be Configuration-Ready after a reset, such as a Function-Level Reset (FLR), a soft reset during a D3hot-> D0uninitialized transition when No_Soft_Reset == 0), or a power-up sequence from D3cold->D0uninitialized. If pci_dev_wait() returns success, the device is guaranteed to respond to configuration requests with Successful Completion status. If it times out, device is completely non-responsive. Upgrade the log level from pci_warn() to pci_err() to reflect this failure state. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Link: https://patch.msgid.link/20260518191220.636213-2-bhelgaas@google.com
2026-05-18drm/amd/display: Fix eDP receiver ready status check in T7 sequenceSung-huai Wang
[Why] Some eDP panels return sinkstatus as 0x5, causing the original sinkstatus == 1 check to never match and resulting in unnecessary polling delay. The equality check is too restrictive and doesn't properly validate the specific status bit that indicates receiver readiness. [How] Replace direct value comparison with proper bitmask check using DP_RECEIVE_PORT_0_STATUS constant. Reviewed-by: Wenjing Liu <wenjing.liu@amd.com> Signed-off-by: Sung-huai Wang <Danny.Wang@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18Revert "drm/amd/display: dmub_cmd.h: add missing kernel-doc for enums"James Lin
[Why & How] This reverts commit f71d0b68ec58b781f4f44ea642846bedce075e85. 1. Auto-generated Header: The file 'dmub_cmd.h' is an auto-generated header managed in an external repository (dmu_stg). Manual changes made directly in this repository will be overwritten and lost during the next automated weekly synchronization. 2. Tooling Compatibility: This header is governed by internal AMD firmware standards which require Doxygen formatting for cross-team documentation. Moving to kernel-doc syntax may break internal documentation pipelines. 3. Suppressing Warnings: Current 'make htmldocs' and 'make W=1' builds do not actively scan 'dmub_cmd.h' for kernel-doc compliance, thus no warnings are triggered during standard compilation. To address warnings generated when manually running './scripts/kernel-doc', we have added a notice at the file header indicating that this is an auto-generated file that does not strictly follow kernel-doc formatting. This ensures that any future linting tools or manual checks recognize the formatting as intentional. Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: James Lin <pinglei.lin@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amd/display: Add some missing code for dcn42James Lin
[why & how] Some DCN4.2 related code is missing from upstream Fixes: e56e3cff2a1b ("drm/amd/display: Sync dcn42 with DC 3.2.373") Acked-by: ChiaHsuan Chung <ChiaHsuan.Chung@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: James Lin <pinglei.lin@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amd: Reduce code duplication in runtime PMMario Limonciello
[Why] amdgpu_pmops_runtime_suspend() runs almost the same code that amdgpu_pmops_runtime_idle() runs. That is there is pointless code duplication. [How] Move amdgpu_pmops_runtime_idle() up, extract common code and then call from both functions. No intended functional changes. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdkfd: Check bounds for allocate_sdma_queue restore_sdma_idDavid Francis
allocate_sdma_queue has an option where the sdma queue id can be specified (used by CRIU). We weren't bounds-checking that value. Confirm it's less than the maximum number of queues. Signed-off-by: David Francis <David.Francis@amd.com> Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu: use atomic operation to achieve lockless serializationSunil Khatri
In amdgpu_seq64_alloc there is a possibility that two difference cores from two separate NODES can try to and could get the same free slot. So this fixes that race here using atomic test_and_set clear operations. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu/vce3: Fix VCE 3 firmware size and offsetsTimur Kristóf
The VCPU BO contains the actual FW at an offset, but it was not calculated into the VCPU BO size. Subtract this from the FW size to make sure there is no out of bounds access. This may fix VM faults when using VCE 3. Cc: John Olender <john.olender@gmail.com> Fixes: e98226221467 ("drm/amdgpu: recalculate VCE firmware BO size") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdkfd: Check bounds on allocate_doorbellDavid Francis
allocated_doorbell has an option to set the doorbell id to a specific value (used by CRIU). This value was not bounds checked. Check to confirm it's less than KFD_MAX_NUM_OF_QUEUES_PER_PROCESS. Signed-off-by: David Francis <David.Francis@amd.com> Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu/vce2: Fix VCE 2 firmware size and offsetsTimur Kristóf
The VCPU BO contains the actual FW at an offset, but it was not calculated into the VCPU BO size. Subtract this from the FW size to make sure there is no out of bounds access. Additionally, increase the VCE_V2_0_DATA_SIZE to have extra space after the VCE handles. Also increase the data size used for each VCE handle. The FW needs 23744 bytes, use 24K to be safe. This fixes VM faults when using VCE 2. Cc: John Olender <john.olender@gmail.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/4802 Fixes: e98226221467 ("drm/amdgpu: recalculate VCE firmware BO size") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu/vce1: Stop using amdgpu_vce_resumeTimur Kristóf
The VCE1 firmware works slightly differently and is already loaded by vce_v1_0_load_fw(). It doesn't actually need to call amdgpu_vce_resume(). Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu/vce1: Fix VCE 1 firmware size and offsetsTimur Kristóf
The VCPU BO contains the actual FW at an offset, but it was not calculated into the VCPU BO size. Subtract this from the FW size to make sure there is no out of bounds access. Make sure the stack and data offsets are aligned to the 32K TLB size. Check that the FW microcode actually fits in the space that is reserved for it. Fixes: d4a640d4b9f3 ("drm/amdgpu/vce1: Implement VCE1 IP block (v2)") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu/vce1: Don't repeat GTT MGR node allocationTimur Kristóf
Only allocate entries from the GTT manager when the VCE GTT node is not allocated yet. This prevents the possibility of allocating them multiple times, which causes issues during GPU reset and suspend/resume. Fixes: 71aec08f80e7 ("amdgpu/vce: use amdgpu_gtt_mgr_alloc_entries") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu/vce1: Check if VRAM address is lower than GART.Timur Kristóf
Previously, I had assumed this was not possible so it was OK to not handle it, but now we got a report from a user who has a board that is configured this way. When the VCPU BO is already located in a low 32-bit address in VRAM (eg. when VRAM is mapped to the low address space), don't do the workaround. Fixes: 71aec08f80e7 ("amdgpu/vce: use amdgpu_gtt_mgr_alloc_entries") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu/vce1: Remove superfluous address checkTimur Kristóf
The same thing is already checked a few lines above. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu/vce1: Check that the GPU address is < 128 MiBTimur Kristóf
When ensuring the low 32-bit address, make sure it is less than 128 MiB, otherwise the VCE seems to fail to initialize. This seems to be an undocumented limitation of the firmware validation mechanism. Note that in case of VCE1 the BAR address is zero and we can't change it also due to the firmware validator. When programming the mmVCE_VCPU_CACHE_OFFSETn registers, don't AND them with a mask. This is incorrect because the register mask is actually 0x0fffffff and useless because we already ensure the addresses are below the limit. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu: Align amdgpu_gtt_mgr entries to TLB size on Tahiti (v2)Timur Kristóf
The TLB is organized in groups of 8 entries, each one is 4K. On Tahiti, the HW requires these GART entries to be 32K-aligned. This fixes a VCE 1 firmware validation failure that can happen after suspend/resume since we use amdgpu_gtt_mgr for VCE 1. v2: - Change variable declaration order - Add comment about "V bit HW bug" Fixes: 698fa62f56aa ("drm/amdgpu: Add helper to alloc GART entries") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdkfd: Fix OOB memory exposure in get_wave_state()Sunday Clement
The get_wave_state() function for v9 trusts cp_hqd_cntl_stack_size and cp_hqd_cntl_stack_offset values read directly from the MQD, which are written by GPU microcode and fully attacker-controlled on the CRIU-restore path (via AMDKFD_IOC_RESTORE_PROCESS with H3). this leads to an unbounded copy_to_user() that can leak adjacent GTT/kernel memory. If offset > size, integer underflow produces a ~4 GiB read length, if size is set to 1 MiB against a 4 KiB allocation, we leak 1 MiB of adjacent kernel memory (other queues' MQDs, ring buffers, KASLR pointers). Fix by clamping both cp_hqd_cntl_stack_size to the actual allocated buffer size (q->ctl_stack_size) and cp_hqd_cntl_stack_offset to the clamped size before performing arithmetic and copy_to_user(). This ensures we never read beyond the allocated kernel BO regardless of attacker-supplied MQD field values. Signed-off-by: Sunday Clement <Sunday.Clement@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amd/pm: fix memleak of dpm_policies on smu v15Yang Wang
In smu_v15_0_fini_smc_tables, dpm_policies was not freed or NULLed, causing a memory leak. Add kfree() and NULL assignment to properly release memory and avoid dangling pointers. Fixes: 2beedc3a92b7 ("drm/amd/pm: Add initial support for smu v15_0_8"); Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdkfd: Enable SDMA queue reset on gfx v12.1Amber Lin
After suspend/resume sdma_gang is supported on MES 12.1, SDMA queue reset is supported too. Signed-off-by: Amber Lin <Amber.Lin@amd.com> Reviewed-by: Michael Chen<michael.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu: Support MES suspend_all_sdma_gangsAmber Lin
suspend_all_sdma_gangs is supported in new MES firmware for gfx 12.1 Signed-off-by: Amber Lin <Amber.Lin@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Michael Chen<michael.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu: fix OOB risk parsing virt RAS batch trace replies on the VFChenglei Xie
amdgpu_virt_ras_get_batch_records() indexed batchs[] and records[] from ras_cmd_batch_trace_record_rsp copied out of shared memory without fully bounding the cache window or per-batch offset/trace_num. A tampered or corrupted buffer could set real_batch_num past the array, make a naive start_batch_id + real_batch_num comparison wrap in uint64_t, or point offset+trace_num past records[]. Add amdgpu_virt_ras_check_batch_cached() for a subtraction-based window with a real_batch_num cap, re-run it after GET_BATCH_TRACE_RECORD, and use an explicit batch index into batchs[]. Consolidate batch_id, trace_num, and offset+trace_num checks; on any failure memset the cache and return -EIO so the next call refetches. Signed-off-by: Chenglei Xie <Chenglei.Xie@amd.com> Reviewed-by: YiPeng Chai <YiPeng.Chai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu: Add guest driver CUID supportchong li
v3: improve the coding style. v2: use debugfs_create_x64 and debugfs_create_x8 to create node. v1: 1. Add guest driver CUID support 2. Do not expose vf index(variable "fcn_idx") to customers, replace the fcn_idx with pad. Only expose the unitid to customers. background: Change fcn_idx to pad, VF index won't expose to guest vm. Introduce a new unitid field as the VF identifier to replace the VF index: 1).unitid is assigned by the host driver 2).It is delivered to the guest via the pf2vf message 3).The application or umd can retrieve united from the sysfs node Signed-off-by: chong li <chongli2@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu: Fix discovery offset check under VFLijo Lazar
Discovery table may be kept at offset 0 by host driver. Remove the validation check. Fixes: 01bdc7e219c4 ("drm/amdgpu: New interface to get IP discovery binary v3") Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Ellen Pan <yunru.pan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu: remove va cursors for all mappingsSunil Khatri
va_cursor struct needs to be cleaned even if the mapping has been removed already. Also simplify it by make it a void function as return value check isn't needed as its called during tear down. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu: reject non-user addresses early in GEM_USERPTR ioctlAmir Shetaia
amdgpu_gem_userptr_ioctl() currently accepts any value of args->addr and only discovers an out-of-range pointer much later, inside amdgpu_gem_object_create() and the HMM mirror registration path. Userspace can drive that path with kernel-side virtual addresses; the get_user_pages() layer rejects them, but only after the driver has already allocated a GEM object and started wiring up notifier state that then has to be torn down on failure. Add an access_ok() guard at the top of the ioctl, right after the existing page-alignment check and before flag validation, so any address that does not lie within the calling task's user address range is rejected with -EFAULT before any allocation occurs. No legitimate ROCm/HSA userspace passes kernel-mode pointers through this interface, so this is defense-in-depth rather than a behaviour change for valid callers; -EFAULT matches the convention already used by other uaccess-style rejections in the kernel. Also add an explicit #include <linux/uaccess.h>; access_ok() is otherwise only available transitively through other headers in this translation unit. Signed-off-by: Amir Shetaia <Amir.Shetaia@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18watchdog: ziirave_wdt: Use named initializers for struct i2c_device_idUwe Kleine-König (The Capable Hub)
While being less compact, using named initializers allows to more easily see which members of the structs are assigned which value without having to lookup the declaration of the struct. And it's also more robust against changes to the struct definition. This patch doesn't modify the compiled arrays, only their representation in source form benefits. The former was confirmed with x86 and arm64 builds. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20260518171901.904094-2-u.kleine-koenig@baylibre.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-05-18drm/amdgpu/vpe: Force collaborate sync after TRAPAlan Liu
VPE1 could possibly hang and fail to power off at the end of commands in collaboration mode. This workaround adds a COLLAB_SYNC after TRAP to force instances synchronized to avoid VPE1 fail to power off. Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Alan liu <haoping.liu@amd.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5171 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu/userq: update the vm task info during signal ioctlSunil Khatri
Pagefaults does not have process information correctly populated as vm->task is not set during vm_init but should be updated while real submission. So setting that up during signal_ioctl to get the correct submission process details. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu/userq: cancel reset work while tear down in progressSunil Khatri
While tear down of a userq_mgr is happening when all the queues are free we should cancel any reset work if pending before exiting. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-18drm/amdgpu: Remove UML build exclusion from KconfigHarry Wentland
The depends on !UML was added in commit dffe68131707 ("amdgpu: Avoid building on UML") to work around build failures with allyesconfig on UML. The original errors were: - smu7_hwmgr.c: incompatible pointer type 'struct cpuinfo_um *' vs 'struct cpuinfo_x86 *' in intel_core_rkl_chk() - kfd_topology.c: 'struct cpuinfo_um' has no member named 'apicid' Both issues have since been resolved independently: - intel_core_rkl_chk() has been removed entirely. - kfd_topology.c now uses a proper #ifdef CONFIG_X86_64 guard. - All other cpuinfo_x86/cpu_data() references in the driver are guarded by #if IS_ENABLED(CONFIG_X86) or #ifdef CONFIG_X86_64. Removing this exclusion allows CONFIG_DRM_AMDGPU to be selected on UML, which in turn enables running KUnit tests (such as amdgpu_dm_crc_test) under UML without needing a full hardware-capable kernel build. Reviewed-by: Alex Hung <alex.hung@amd.com> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-07-10 19:00:24 +0000