summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-05-11selftests: mptcp: join: validate 8x8 subflowsMatthieu Baerts (NGI0)
The limits have been recently increased, it is required to validate that having 64 subflows is allowed. Here, both the client and the server have 8 network interfaces. The server has 8 endpoints marked as 'signal' to announce all its v4 addresses. The client also has 8 endpoints, but marked as 'subflow' and 'fullmesh' in order to create 8 subflows to each address announced by the server. This means 63 additional subflows will be created after the initial one. If it is not possible to increase the limits to 64, it means an older kernel version is being used, and the test is skipped. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260508-net-next-mptcp-pm-inc-limits-v1-6-c84e3fdf9b6a@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-11selftests: mptcp: join: allow changing ifaces nr per testMatthieu Baerts (NGI0)
By default, 4 network interfaces are created per subtest in a dedicated net namespace. Each netns has a dedicated pair of v4 and v6 addresses. Future tests will need more. Simply always creating more network interfaces per test will increase the execution time for all other tests, for no other benefits. So now it is possible to change this number only when needed, by setting ifaces_nr when calling 'reset' and 'init_shapers', e.g. ifaces_nr=8 reset "Subtest title" ifaces_nr=8 init_shapers Note that it might also be interesting to decrease the default value to 2 to reduce the setup time, especially when a debug kernel config is being used. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260508-net-next-mptcp-pm-inc-limits-v1-5-c84e3fdf9b6a@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-11mptcp: pm: in-kernel: increase endpoints limitMatthieu Baerts (NGI0)
The endpoints are managed in a list which was limited to 8 entries. This limit can be too small in some cases: by having the same limit as the number of subflows, it might not allow creating all expected subflows when having a mix of v4 and v6 addresses that can all use MPTCP on v4/v6 only networks. While increasing the limit above the new subflows one, why not using the technical limit: 255. Indeed, the endpoint will each have an ID that will be used on the wire, limited to u8, and the ID 0 is reserved to the initial subflow. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260508-net-next-mptcp-pm-inc-limits-v1-4-c84e3fdf9b6a@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-11mptcp: pm: kernel: allow flushing more than 8 endpointsMatthieu Baerts (NGI0)
The mptcp_rm_list structure contains an array of IDs of 8 entries: to be able to send a RM_ADDR with 8 IDs. This limitation was OK so far because there could maximum 8 endpoints. But this is going to change in the next commit. To cope with that, if one of the arrays is full, the iteration stops, the lists are processed, then the iteration continues where it previously stopped. Note that if there are many endpoints to remove, and multiple RM_ADDR to send, it might be more likely that some of these RM_ADDRs are dropped or lost. This is a known limitation: RM_ADDR are not retransmitted in MPTCPv1. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260508-net-next-mptcp-pm-inc-limits-v1-3-c84e3fdf9b6a@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-11mptcp: pm: in-kernel: increase all limits to 64Matthieu Baerts (NGI0)
This means switching the maximum from 8 to 64 for the number of subflows and accepted ADD_ADDR. The previous limit of 8 subflows makes sense in most cases. Using more subflows will very likely *not* improve the situation, and could even decrease the performances. But there are no technical limitations nor performance impact to raise this limit, so let's do it: this will allow people with very specific use-cases, and researchers to easily create more subflows, and measure the performance impact by themselves. The theoretical limit is 255 -- the ID is written in a u8 on the wire -- but 64 is more than enough. With so many subflows, it will be costly to iterate over all of them when operations are done in bottom half. Note that the in-kernel PM will continue to create subflows in reply to ADD_ADDR with a single batch of maximum 8 subflows. Same when adding new "subflow" endpoints with the fullmesh flag. Increasing those batch limits would have a memory impact, and it looks fine not to cover these cases with larger batches for the moment. If more is needed later, the position of the last subflow from the list could be remembered, and the list iteration could continue later. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/434 Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260508-net-next-mptcp-pm-inc-limits-v1-2-c84e3fdf9b6a@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-11mptcp: pm: in-kernel: explicitly limit batches to array sizeMatthieu Baerts (NGI0)
The in-kernel PM can create subflows in reply to ADD_ADDR by batch of maximum 8 subflows for the moment. Same when adding new "subflow" endpoints with the fullmesh flag. This limit is linked to the arrays used during these steps. There was no explicit limit to the arrays size (8), because the limit of extra subflows is the same (8). It seems safer to use an explicit limit, but also these two sizes are going to be different in the next commit. Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260508-net-next-mptcp-pm-inc-limits-v1-1-c84e3fdf9b6a@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-11arm64: dts: qcom: glymur: Drop RPMh CXO clocks from QMP PHYsAbel Vesa
On Glymur, all QMP PHYs except the one used by USB SS0 take their reference clock from the TCSR clock controller. Since these TCSR clocks already derive from RPMH_CXO_CLK as their sole parent, there is no need to provide an extra `clkref` clock to the PHY nodes. Drop the extra RPMh CXO clock inputs and use the TCSR clocks as the PHY reference clocks instead. This also fixes the devicetree schema validation, as the bindings do not allow a separate `clkref` clock. Fixes: 4eee57dd4df9 ("arm64: dts: qcom: glymur: Add USB related nodes") Reported-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reported-by: Rob Herring <robh@kernel.org> Closes: https://lore.kernel.org/r/20260410145205.GA554754-robh@kernel.org/ Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260414-dts-glymur-drop-rpmh-cxo-clk-from-qmpphys-v1-1-ab12d77c4aec@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-11arm64: dts: qcom: glymur: Mark USB SS1 and SS2 as role-switch capableAbel Vesa
Like USB SS0, the USB SS1 and SS2 controllers on Glymur also support USB role switching. Describe this by adding the 'usb-role-switch' property to both controllers. Fixes: 4eee57dd4df9 ("arm64: dts: qcom: glymur: Add USB related nodes") Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260415-dts-qcom-glymur-usb-role-switch-fix-v1-1-409e1a257f1f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-11arm64: dts: qcom: glymur-crd: Drop forced host mode for USB SS0 and SS1Abel Vesa
The two USB Type-C ports on Glymur CRD are dual-role capable. Do not force their controllers into host mode. Drop the explicit 'dr_mode = "host"' properties so they can use their default OTG mode instead. Fixes: c8b63029455b ("arm64: dts: qcom: glymur-crd: Enable USB support") Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260415-dts-qcom-glymur-usb-role-switch-fix-v1-2-409e1a257f1f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-11tcp: Fix out-of-bounds access for twsk in tcp_ao_established_key().Kuniyuki Iwashima
lockdep_sock_is_held() was added in tcp_ao_established_key() by the cited commit. It can be called from tcp_v[46]_timewait_ack() with twsk. Since it does not have sk->sk_lock, the lockdep annotation results in out-of-bound access. $ pahole -C tcp_timewait_sock vmlinux | grep size /* size: 288, cachelines: 5, members: 8 */ $ pahole -C sock vmlinux | grep sk_lock socket_lock_t sk_lock; /* 440 192 */ Let's not use lockdep_sock_is_held() for TCP_TIME_WAIT. Fixes: 6b2d11e2d8fc ("net/tcp: Add missing lockdep annotations for TCP-AO hlist traversals") Reported-by: Damiano Melotti <melotti@google.com> Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260508120853.4098365-1-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-12tools/bootconfig: render kernel.* subtree as cmdline string with -CBreno Leitao
Add a -C option that finds the "kernel" subtree of a bootconfig file and prints it as a flat, space-separated cmdline string by calling the shared xbc_snprint_cmdline() renderer. An empty or absent kernel.* subtree produces empty output and exits successfully. This lets the kernel build embed a bootconfig file as a plain cmdline string at build time, so embedded bootconfig values can reach parse_early_param() during architecture setup without parsing the bootconfig at runtime. The renderer is intentionally limited to the kernel.* subtree: that is the only thing the kernel build needs to embed; init.* and other subtrees keep going through the runtime parser. Example of this new mode: # cat /tmp/test.bconf kernel { foo = bar baz = "hello world" arr = 1, 2 } init.foo = nope # ./tools/bootconfig/bootconfig -C /tmp/test.bconf foo=bar baz="hello world" arr=1 arr=2 % Link: https://lore.kernel.org/all/20260508-bootconfig_using_tools-v1-2-1132219aa773@debian.org/ Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-05-12bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.cBreno Leitao
Move xbc_snprint_cmdline() from init/main.c to lib/bootconfig.c so the function (and its xbc_namebuf scratch buffer) becomes part of the shared parser library. tools/bootconfig already compiles lib/bootconfig.c directly, which lets a follow-up patch reuse the same renderer in the userspace tool to convert a bootconfig file into a flat cmdline string at build time. No functional change. Link: https://lore.kernel.org/all/20260508-bootconfig_using_tools-v1-1-1132219aa773@debian.org/ Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-05-11net: mention the convention for .ndo_setup_tc()David Yang
qdisc_offload_dump_helper(), originated from commit 602f3baf2218 ("net_sch: red: Add offload ability to RED qdisc"), is designed to that Whether RED is being offloaded is being determined every time dump action is being called because parent change of this qdisc could change its offload state but doesn't require any RED function to be called. and returning -EOPNOTSUPP (for dump queries) does not mean "I don't have any statistics", but "I don't offload this qdisc anymore". At least two existing drivers did it wrong, so it is worth mentioning. Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20260507214054.2539790-1-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-11net: ena: PHC: Check return code before setting timestamp outputArthur Kiyanovski
ena_phc_gettimex64() is setting the output parameter regardless of whether ena_com_phc_get_timestamp() succeeded or failed. When ena_com_phc_get_timestamp() returns an error, the timestamp parameter may contain uninitialized stack memory (e.g., when PHC is disabled or in blocked state) or invalid hardware values. Passing these to userspace via the PTP ioctl is both a security issue (information leak) and a correctness bug. Fix by checking the return code after releasing the lock and only setting the output timestamp on success. Fixes: e0ea34158ee8 ("net: ena: Add PHC support in the ENA driver") Cc: stable@vger.kernel.org Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260507003518.22554-1-akiyano@amazon.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-11net/rds: reset op_nents when zerocopy page pin failsAllison Henderson
When iov_iter_get_pages2() fails in rds_message_zcopy_from_user(), the pinned pages are released with put_page(), and rm->data.op_mmp_znotifier is cleared. But we fail to properly clear rm->data.op_nents. Later when rds_message_purge() is called from rds_sendmsg() the cleanup loop iterates over the incorrectly non zero number of op_nents and frees them again. Fix this by properly resetting op_nents when it should be in rds_message_zcopy_from_user(). Fixes: 0cebaccef3ac ("rds: zerocopy Tx support.") Signed-off-by: Allison Henderson <achender@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260505234336.2132721-1-achender@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-11dt-bindings: PCI: intel,lgm-pcie: Add 'atu' resourceFlorian Eckert
The 'atu' information is already set in the dwc core, if it is specified in the devicetree. The driver uses its own default, if not set in the devicetree. This information is hardware-specific and should therefore be maintained in the devicetree rather than in the source. To be backward compatible, this field is not mandatory. If 'atu' resource is not specified in the devicetree, the driver’s default value is used. Signed-off-by: Florian Eckert <fe@dev.tdt.de> 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/20260417-pcie-intel-gw-v5-7-0a2b933fe04f@dev.tdt.de
2026-05-11PCI: intel-gw: Fix ATU base address setup and add optional DT 'atu' regionFlorian Eckert
The ATU base address was set in intel_pcie_host_setup(), which is called via pp->ops->init(). However, dw_pcie_get_resources() runs before this callback and sets a default atu_base of 0x300000, which then gets overwritten by the driver's value of 0xC0000. But this ordering is broken because atu_base must be set before dw_pcie_get_resources() runs, not after. So move the atu_base assignment from intel_pcie_host_setup() to intel_pcie_probe() to fix the initialization order. The call stack is: intel_pcie_probe dw_pcie_host_init dw_pcie_host_get_resources dw_pcie_get_resources <- sets atu_base = 0x300000 pp->ops->init intel_pcie_rc_init intel_pcie_host_setup <- was overwriting atu_base here Additionally, add support for parsing the ATU region from the device tree. If an 'atu' region is present in DT, the DWC core parses it via dw_pcie_get_resources() and the driver does not set atu_base explicitly. If 'atu' is absent, the driver falls back to the hardcoded offset (0xC0000 from DBI base) for backwards compatibility, with a warning to the user. Signed-off-by: Florian Eckert <fe@dev.tdt.de> [mani: commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-6-0a2b933fe04f@dev.tdt.de
2026-05-11PCI: intel-gw: Add .start_link() callbackFlorian Eckert
The pcie-intel-gw driver had no .start_link() callback. Add one so the driver works again and does not abort with the following error messages during probing: intel-gw-pcie d1000000.pcie: host bridge /soc/pcie@d1000000 ranges: intel-gw-pcie d1000000.pcie: MEM 0x00dc000000..0x00ddffffff -> 0x00dc000000 intel-combo-phy d0c00000.combo-phy: Set combo mode: combophy[1]: mode: PCIe single lane mode intel-gw-pcie d1000000.pcie: No outbound iATU found intel-gw-pcie d1000000.pcie: Cannot initialize host intel-gw-pcie d1000000.pcie: probe with driver intel-gw-pcie failed with error -22 intel-gw-pcie c1100000.pcie: host bridge /soc/pcie@c1100000 ranges: intel-gw-pcie c1100000.pcie: MEM 0x00ce000000..0x00cfffffff -> 0x00ce000000 intel-combo-phy c0c00000.combo-phy: Set combo mode: combophy[3]: mode: PCIe single lane mode intel-gw-pcie c1100000.pcie: No outbound iATU found intel-gw-pcie c1100000.pcie: Cannot initialize host intel-gw-pcie c1100000.pcie: probe with driver intel-gw-pcie failed with error -22 Fixes: c5097b9869a1 ("Revert "PCI: dwc: Wait for link up only if link is started"") Fixes: da56a1bfbab5 ("PCI: dwc: Wait for link up only if link is started") Signed-off-by: Florian Eckert <fe@dev.tdt.de> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: remove timestamps] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-5-0a2b933fe04f@dev.tdt.de
2026-05-11PCI: intel-gw: Enable clock before PHY initFlorian Eckert
To ensure that the boot sequence is correct, the DWC PCIe core clock must be switched on before PHY init call [1]. This changes are based on patched kernel sources of the MaxLinear SDK. The reason why the MaxLinear SDK is used as a reference here is, that this PCIe DWC IP is used in the URX851 and URX850 SoC. This SoC was originally developed by Intel when they acquired Lantiq’s home networking division in 2015 [2]. In 2020 the home network division was sold to MaxLinear [3]. Since then, this SoC belongs to MaxLinear. They use their own SDK, which runs on kernel version '5.15.x'. [1] https://github.com/maxlinear/linux/blob/updk_9.1.90/drivers/pci/controller/dwc/pcie-intel-gw.c#L544 [2] https://www.intc.com/news-events/press-releases/detail/364/intel-to-acquire-lantiq-advancing-the-connected-home [3] https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform Signed-off-by: Florian Eckert <fe@dev.tdt.de> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-4-0a2b933fe04f@dev.tdt.de
2026-05-11PCI: intel-gw: Move interrupt enable to own functionFlorian Eckert
To improve the readability of the code, move the interrupt enable instructions to a separate function. That is already done for the disable interrupt instruction. In addition, clear and disable all pending interrupts, as is done in intel_pcie_core_irq_disable(). After that, enable all relevant interrupts again. The 'PCIE_APP_IRNEN' definition contains all the relevant interrupts that are of interest. This change is also done in the MaxLinear SDK [1]. As I unfortunately don’t have any documentation for this IP core, I suspect that the intention is to set the IP core for interrupt handling to a specific state. Perhaps the problem is that the IP core did not reinitialize the interrupt register properly after a power cycle. In my view, it can’t do any harm to switch the interrupt off and then on again to set them to a specific state. The reason why the MaxLinear SDK is used as a reference here is, that this PCIe DWC IP is used in the URX851 and URX850 SoC. This SoC was originally developed by Intel when they acquired Lantiq’s home networking division in 2015 [2]. In 2020 the home network division was sold to MaxLinear [3]. Since then, this SoC belongs to MaxLinear. They use their own SDK, which runs on kernel version '5.15.x'. [1] https://github.com/maxlinear/linux/blob/updk_9.1.90/drivers/pci/controller/dwc/pcie-intel-gw.c#L431 [2] https://www.intc.com/news-events/press-releases/detail/364/intel-to-acquire-lantiq-advancing-the-connected-home [3] https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform Signed-off-by: Florian Eckert <fe@dev.tdt.de> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-3-0a2b933fe04f@dev.tdt.de
2026-05-11PCI: intel-gw: Remove unused PCIE_APP_INTX_OFST definitionFlorian Eckert
The C preprocessor define 'PCIE_APP_INTX_OFST' is not used in the sources. Delete it. Signed-off-by: Florian Eckert <fe@dev.tdt.de> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-2-0a2b933fe04f@dev.tdt.de
2026-05-11arm64: dts: qcom: ipq9650: add watchdog nodeKathiravan Thirumoorthy
Add the watchdog device node for IPQ9650 SoC. Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260511-ipq9650_wdt-v1-1-1948934c1e12@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-11arm64: dts: qcom: add IPQ9650 SoC and rdp488 board supportKathiravan Thirumoorthy
Add initial device tree support for the Qualcomm IPQ9650 SoC and rdp488 board. Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260507-ipq9650_boot_to_shell-v3-4-62742b49c991@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-11dt-bindings: qcom: add IPQ9650 boardsKathiravan Thirumoorthy
Document the new IPQ9650 SoC/board device tree bindings. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260507-ipq9650_boot_to_shell-v3-3-62742b49c991@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-11Merge branch ↵Bjorn Andersson
'20260507-ipq9650_boot_to_shell-v3-1-62742b49c991@oss.qualcomm.com' into arm64-for-7.2 Merge the QCS9650 GCC DeviceTree binding from topic branch, to get access to clock and reset constants.
2026-05-11clk: qcom: add Global Clock controller (GCC) driver for IPQ9650 SoCKathiravan Thirumoorthy
Add support for the global clock controller found on IPQ9650 SoC. Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260507-ipq9650_boot_to_shell-v3-2-62742b49c991@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-11Merge branch ↵Bjorn Andersson
'20260507-ipq9650_boot_to_shell-v3-1-62742b49c991@oss.qualcomm.com' into clk-for-7.2 Merge the IPQ9650 GCC DeviceTree binding, to allow constants to be made available to DeviceTree source tree as well.
2026-05-11dt-bindings: clock: add Qualcomm IPQ9650 GCCKathiravan Thirumoorthy
Add binding for the Qualcomm IPQ9650 Global Clock Controller. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260507-ipq9650_boot_to_shell-v3-1-62742b49c991@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-11MAINTAINERS: Remove Chuanhua Lei as PCIe intel-gw maintainerFlorian Eckert
Chuanhua Lei's email address has been bouncing for months. Remove the entry and mark the PCI intel-gw driver as orphaned. Signed-off-by: Florian Eckert <fe@dev.tdt.de> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-1-0a2b933fe04f@dev.tdt.de
2026-05-11selftests/bpf: Use both hrtimer enqueue helpers in vmlinux testIhor Solodrai
The vmlinux selftest triggers nanosleep and checks that both kprobe and fentry programs observe the hrtimer enqueue path. After the hrtimer_start_expires_user() conversion [1], nanosleep reaches hrtimer_start_range_ns_user() instead of hrtimer_start_range_ns(). Hard-coding either symbol makes the test fail either on bpf tree or on linux-next [2]. Update the test to resolve the target symbol at runtime via libbpf_find_vmlinux_btf_id(). This is a nice example of how to modify a BPF program to work on both older and newer kernel revision. [1] https://lore.kernel.org/all/20260408114952.062400833@kernel.org/ [2] https://github.com/kernel-patches/bpf/actions/runs/25485909958/job/74782902203 Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Acked-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20260509005730.250956-1-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11hfsplus: rework hfsplus_readdir() logicViacheslav Dubeyko
The xfstests' test-case generic/637 fails with error: FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.15.0-rc4+ #8 SMP PREEMPT_DYNAMIC Thu May 1 16:43:22 PDT 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch QA output created by 637 entries 7 and 8 have duplicate d_off 8 Found unlinked files in open dir (see xfstests-dev/results//generic/637.full for details) Debugging of the hfsplus_readdir() logic showed this: hfsplus: hfsplus_readdir(): 163 ctx->pos 0 hfsplus: hfsplus_readdir(): 189 ctx->pos 1 hfsplus: hfsplus_readdir(): 264 ctx->pos 2, ino 18 hfsplus: hfsplus_readdir(): 264 ctx->pos 3, ino 19 hfsplus: hfsplus_readdir(): 264 ctx->pos 4, ino 28 hfsplus: hfsplus_readdir(): 264 ctx->pos 5, ino 118 hfsplus: hfsplus_readdir(): 264 ctx->pos 6, ino 29 hfsplus: hfsplus_readdir(): 264 ctx->pos 7, ino 30 hfsplus: hfsplus_readdir(): 264 ctx->pos 8, ino 31 hfsplus: hfsplus_readdir(): 304 ctx->pos 8 hfsplus: hfsplus_unlink():420 dir->i_ino 17, inode->i_ino 28 hfsplus: hfsplus_readdir(): 141 ctx->pos 7 hfsplus: hfsplus_readdir(): 264 ctx->pos 7, ino 31 hfsplus: hfsplus_readdir(): 264 ctx->pos 8, ino 32 hfsplus: hfsplus_readdir(): 264 ctx->pos 9, ino 33 It means that hfsplus_readdir() stopped the processing of folder's items on ctx->pos 8, then, item with ino 28 has been deleted and hfsplus_readdir() re-started the logic from ctx->pos 7. As a result, previous and new sets of folder's items have overlapping values for the case of d_off 8. Currently, HFS+ has very complicated and fragile logic of rd->file->f_pos correction in hfsplus_delete_cat(). This patch removes this logic and it stores the current pos into hfsplus_readdir_data. Finally, if rd->pos == ctx->pos then hfsplus_readdir() tries to find the position in b-tree's node by means of hfsplus_cat_key. This position is used to re-start the folder's content traversal. sudo ./check generic/637 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.1.0-rc1+ #44 SMP PREEMPT_DYNAMIC Mon May 4 15:58:45 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/637 22s ... 22s Ran: generic/637 Passed all 1 tests Closes: https://github.com/hfs-linux-kernel/hfs-linux-kernel/issues/198 cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> cc: Yangtao Li <frank.li@vivo.com> cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260505220051.2854696-2-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-05-12zonefs: handle integer overflow in zonefs_fname_to_fnoJohannes Thumshirn
In zonefs the file name in one of the two directories corresponds to the zone number. Here Alexey reported a possible integer overflow in zonefs_fname_to_fno(), where the parsing of the zone number from the file name can overflow the 'long' data type. Add a check for integer overflows and if the fno 'long' did overflow return -ENOENT. Reported-by: Alexey Dobriyan <adobriyan@gmail.com> Fixes: d207794ababe ("zonefs: Dynamically create file inodes when needed") Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2026-05-11Merge branch 'for-7.1-fixes' into for-7.2Tejun Heo
Pull to receive: 9a415cc53711 ("sched_ext: Avoid UAF in scx_root_enable_workfn() init failure path") Conflicts with for-7.2's scx_task_iter_relock() rework. The fix moves put_task_struct(p) past scx_error(); for-7.2 still has it at the old position. Resolved by dropping the old one. Signed-off-by: Tejun Heo <tj@kernel.org>
2026-05-11Merge tag 'linux_kselftest-kunit-fixes-7.1-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull kunit fixes from Shuah Khan: "Fix to decouple KUNIT_DEBUGFS and KUNIT_ALL_TESTS options and fix KUNIT_DEBUGFS dependencies so it depends on DEBUG_FS without which it will not be useful" * tag 'linux_kselftest-kunit-fixes-7.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: kunit: config: KUNIT_DEBUGFS should depend on DEBUG_FS kunit: config: Enable KUNIT_DEBUGFS by default
2026-05-11Merge branch 'selftests-bpf-add-xdp-load-balancer-benchmark'Alexei Starovoitov
Puranjay Mohan says: ==================== selftests/bpf: Add XDP load-balancer benchmark Changelog: RFC: https://lore.kernel.org/all/20260420111726.2118636-1-puranjay@kernel.org/ Changes in v1: - Replace bpf_get_cpu_time_counter() with bpf_ktime_get_ns() - Replace bpf_repeat() with plain for loop and may_goto - Refactor collect_measurements() to reuse bench_force_done() - Remove histogram, verbose calibration output, and per-scenario status prints - Trim run script table to p50/stddev/p99 - Set env.quiet when --machine-readable is passed - Add || true to run script benchmark invocation for set -e safety - Add bpf-nop benchmark as timing overhead baseline (patch 3) - Use named struct for LRU inner map to fix build on older toolchains This series adds an XDP load-balancer benchmark (based on Katran) to the BPF selftest bench framework. Motivation ---------- Existing BPF bench tests measure individual operations (map lookups, kprobes, ring buffers) in isolation. Production BPF programs combine parsing, map lookups, branching, and packet rewriting in a single call chain. The performance characteristics of such programs depend on the interaction of these operations -- register pressure, spills, inlining decisions, branch layout -- which isolated micro-benchmarks do not capture. This benchmark implements a simplified L4 load-balancer modeled after katran [1]. The BPF program reproduces katran's core datapath: L3/L4 parsing -> VIP hash lookup -> per-CPU LRU connection table with consistent-hash fallback -> real server selection -> per-VIP and per-real stats -> IPIP/IP6IP6 encapsulation The BPF code exercises hash maps, array-of-maps (per-CPU LRU), percpu arrays, jhash, bpf_xdp_adjust_head(), bpf_ktime_get_ns(), and bpf_get_smp_processor_id() in a single pipeline. This is intended as the first in a series of BPF workload benchmarks covering other use cases (sched_ext, etc.). Design ------ A userspace loop calling bpf_prog_test_run_opts(repeat=1) would measure syscall overhead, not BPF program cost -- the ~4 ns early-exit paths would be buried under kernel entry/exit. Using repeat=N is also unsuitable: the kernel re-runs the same packet without resetting state between iterations, so the second iteration of an encap scenario would process an already-encapsulated packet. Instead, timing is measured inside the BPF program using bpf_ktime_get_ns(). BENCH_BPF_LOOP() brackets N iterations with timestamp reads using a plain for loop with may_goto, runs a caller-supplied reset block between iterations to undo side effects (e.g. strip encapsulation), and records the elapsed time per batch. One extra untimed iteration runs afterward for output validation. Auto-calibration picks a batch size targeting ~10 ms per invocation. A proportionality sanity check verifies that 2N iterations take ~2x as long as N. 24 scenarios cover the code-path matrix: - Protocol: TCP, UDP - Address family: IPv4, IPv6, cross-AF (IPv4-in-IPv6) - LRU state: hit, miss (16M flow space), diverse (4K flows), cold - Consistent-hash: direct (LRU bypass) - TCP flags: SYN (skip LRU, force CH), RST (skip LRU insert) - Early exits: unknown VIP, non-IP, ICMP, fragments, IP options Each scenario validates correctness before benchmarking by comparing the output packet byte-for-byte against a pre-built expected packet and checking BPF map counters. Sample single-scenario output: $ sudo ./bench xdp-lb --scenario tcp-v4-lru-hit Setting up benchmark 'xdp-lb'... Benchmark 'xdp-lb' started. tcp-v4-lru-hit: median 74.51 ns/op, stddev 0.11, p99 74.81 (202 samples) Sample run script output: $ ./benchs/run_bench_xdp_lb.sh XDP load-balancer benchmark =========================== +----------------------------------+----------+---------+----------+ | Single-flow baseline | p50 | stddev | p99 | +----------------------------------+----------+---------+----------+ | tcp-v4-lru-hit | 74.30 | 0.08 | 74.48 | | tcp-v4-ch | 101.73 | 0.11 | 102.01 | | tcp-v6-lru-hit | 76.77 | 0.14 | 77.04 | | tcp-v6-ch | 121.40 | 0.10 | 121.65 | | udp-v4-lru-hit | 107.42 | 0.22 | 107.90 | | udp-v6-lru-hit | 110.21 | 0.12 | 110.45 | | tcp-v4v6-lru-hit | 74.82 | 0.35 | 75.43 | +----------------------------------+----------+---------+----------+ | Diverse flows (4K src addrs) | p50 | stddev | p99 | +----------------------------------+----------+---------+----------+ | tcp-v4-lru-diverse | 86.63 | 0.37 | 89.04 | | tcp-v4-ch-diverse | 104.09 | 0.19 | 105.67 | | tcp-v6-lru-diverse | 89.34 | 0.42 | 90.70 | | tcp-v6-ch-diverse | 122.20 | 0.21 | 123.78 | | udp-v4-lru-diverse | 119.37 | 0.58 | 123.10 | +----------------------------------+----------+---------+----------+ | TCP flags | p50 | stddev | p99 | +----------------------------------+----------+---------+----------+ | tcp-v4-syn | 165.52 | 15.68 | 198.34 | | tcp-v4-rst-miss | 161.34 | 2.69 | 172.64 | +----------------------------------+----------+---------+----------+ | LRU stress | p50 | stddev | p99 | +----------------------------------+----------+---------+----------+ | tcp-v4-lru-miss | 440.39 | 35.75 | 550.62 | | udp-v4-lru-miss | 571.88 | 57.38 | 680.61 | | tcp-v4-lru-warmup | 317.75 | 9.55 | 356.20 | +----------------------------------+----------+---------+----------+ | Early exits | p50 | stddev | p99 | +----------------------------------+----------+---------+----------+ | pass-v4-no-vip | 18.26 | 0.13 | 18.66 | | pass-v6-no-vip | 19.08 | 0.01 | 19.10 | | pass-v4-icmp | 6.81 | 0.02 | 6.86 | | pass-non-ip | 5.71 | 0.03 | 5.76 | | drop-v4-frag | 6.09 | 0.01 | 6.10 | | drop-v4-options | 5.88 | 0.00 | 5.89 | | drop-v6-frag | 6.00 | 0.03 | 6.04 | +----------------------------------+----------+---------+----------+ Patches ------- Patch 1 adds bench_force_done() to the bench framework so benchmarks can signal early completion when enough samples have been collected. Patch 2 adds the shared BPF batch-timing library (BPF-side timing arrays, BENCH_BPF_LOOP macro, userspace statistics and calibration). Patch 3 adds a bpf-nop benchmark as a timing overhead baseline and usage example for the timing library. Patch 4 adds the common header shared between the BPF program and userspace (flow_key, vip_definition, real_definition, encap helpers). Patch 5 adds the XDP load-balancer BPF program. Patch 6 adds the userspace benchmark driver with 24 scenarios, packet construction, validation, and bench framework integration. Patch 7 adds the run script for running all scenarios. [1] https://github.com/facebookincubator/katran ==================== Link: https://patch.msgid.link/20260427232313.1582588-1-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11selftests/bpf: Add XDP load-balancer benchmark run scriptPuranjay Mohan
Add a convenience script that runs all 24 XDP load-balancer scenarios and formats the results as a table with median, stddev, and p99 columns. ./benchs/run_bench_xdp_lb.sh Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20260427232313.1582588-8-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11selftests/bpf: Add XDP load-balancer benchmark driverPuranjay Mohan
Wire up the userspace side of the XDP load-balancer benchmark. 24 scenarios cover the full code-path matrix: TCP/UDP, IPv4/IPv6, cross-AF encap, LRU hit/miss/diverse/cold, consistent-hash bypass, SYN/RST flag handling, and early exits (unknown VIP, non-IP, ICMP, fragments, IP options). Before benchmarking each scenario validates correctness: the output packet is compared byte-for-byte against a pre-built expected packet and BPF map counters are checked against the expected values. Usage: sudo ./bench -a -w3 -p1 xdp-lb --scenario tcp-v4-lru-hit sudo ./bench xdp-lb --list-scenarios Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20260427232313.1582588-7-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11selftests/bpf: Add XDP load-balancer BPF programPuranjay Mohan
Add the BPF datapath for the XDP load-balancer benchmark, a simplified L4 load-balancer inspired by katran. The pipeline: L3/L4 parse -> VIP lookup -> per-CPU LRU connection table or consistent-hash fallback -> real server lookup -> per-VIP and per-real stats -> IPIP/IP6IP6 encapsulation. TCP SYN forces the consistent-hash path (skipping LRU); TCP RST skips LRU insert to avoid polluting the table. process_packet() is marked __noinline so that the BENCH_BPF_LOOP reset block (which strips encapsulation) operates on valid packet pointers after bpf_xdp_adjust_head(). Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20260427232313.1582588-6-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11selftests/bpf: Add XDP load-balancer common definitionsPuranjay Mohan
Add the shared header for the XDP load-balancer benchmark. This defines the data structures used by both the BPF program and userspace: flow_key, vip_definition, real_definition, and the stats/control structures. Also provides the encapsulation source-address helpers shared between the BPF datapath (for encap) and userspace (for building expected output packets used in validation). Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20260427232313.1582588-5-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11selftests/bpf: Add bpf-nop benchmark for timing overhead baselinePuranjay Mohan
Add a minimal benchmark that measures the overhead of the batch-timing infrastructure itself. The BPF program runs an empty BENCH_BPF_LOOP body (~1.5-2 ns/op), establishing the floor cost that all timing-library benchmarks include. [root@virtme-ng tools/testing/selftests/bpf]# sudo ./bench -a -p8 bpf-nop Setting up benchmark 'bpf-nop'... Benchmark 'bpf-nop' started. bpf-nop: median 1.82 ns/op, stddev 0.01, p99 1.86 (1754 samples) Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20260427232313.1582588-4-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11selftests/bpf: Add BPF batch-timing libraryPuranjay Mohan
Add a reusable timing library for BPF benchmarks that need to measure BPF program execution time. The BPF side (progs/bench_bpf_timing.bpf.h) provides per-CPU sample arrays and BENCH_BPF_LOOP(), a macro that brackets batch_iters iterations with bpf_ktime_get_ns() reads and records the elapsed time. One extra untimed iteration runs afterward for output validation. The userspace side (benchs/bench_bpf_timing.c) collects samples from the skeleton BSS, computes percentile statistics, and auto-calibrates batch_iters to target ~10 ms per batch. Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20260427232313.1582588-3-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11selftests/bpf: Add bench_force_done() for early benchmark completionPuranjay Mohan
The bench framework waits for duration_sec to elapse before collecting results. Benchmarks that know exactly how many samples they need can call bench_force_done() to signal completion early, avoiding wasted wall-clock time. Also refactor collect_measurements() to reuse bench_force_done() instead of open-coding the same mutex/cond_signal sequence. Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20260427232313.1582588-2-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11sched_ext: Avoid UAF in scx_root_enable_workfn() init failure pathTejun Heo
In scx_root_enable_workfn(), put_task_struct(p) is called before scx_error() dereferences p->comm and p->pid. If the iterator's reference is the last drop, the task is freed synchronously and the deref becomes a UAF. Move put_task_struct() past scx_error(). Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260511214031.AF5E9C2BCB0@smtp.kernel.org/ Fixes: f0e1a0643a59 ("sched_ext: Implement BPF extensible scheduler class") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Tejun Heo <tj@kernel.org>
2026-05-11drm/amdgpu/gfx_v12_0: set gfx.rs64_enable from PFP header on GFX12Jesse Zhang
gfx_v12_0_init_microcode() always loads RS64 CP ucode but never set adev->gfx.rs64_enable, so it stayed false and code that branches on it (e.g. MEC pipe reset) used the legacy CP_MEC_CNTL path incorrectly. Match GFX11: derive RS64 mode from the PFP firmware header (v2.0) via amdgpu_ucode_hdr_version(). Log at debug when RS64 is enabled. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit b03d53598b0d2048e8fa7303b8d0784768ec4fa6)
2026-05-11drm/amd/ras: Fix CPER ring debugfs read overflowXiang Liu
The legacy CPER debugfs reader can reach the payload path without a valid pointer snapshot. The remaining user byte count is also treated as the ring occupancy in dwords, so reads past the header can copy more than requested. Take the CPER lock before sampling pointers. Resample rptr/wptr for payload reads, bound the payload copy by available dwords and the remaining user size, and advance the file position for each dword copied. Signed-off-by: Xiang Liu <xiang.liu@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 1e40ef87ffdc291e05ccdade8b9170cc9c1c4249)
2026-05-11drm/amd/display: Wrap DCN32 phantom-plane allocation in ↵Mikhail Gavrilov
DC_RUN_WITH_PREEMPTION_ENABLED [Why] dcn32_validate_bandwidth() wraps dcn32_internal_validate_bw() with DC_FP_START()/DC_FP_END(). In x86 non-RT, DC_FP_START takes fpregs_lock(), which disables local softirqs. The DML1 path through dcn32_enable_phantom_plane() calls kvzalloc() to allocate ~335 KiB for dc_plane_state. This triggers the vmalloc path, which calls BUG_ON(in_interrupt()) because it's invoked within the FPU-enabled (softirq disabled) region, leading to a kernel crash. [How] Wrap the dc_state_create_phantom_plane() call with the DC_RUN_WITH_PREEMPTION_ENABLED() macro to allow preemption during this memory allocation. Fixes: 235c67634230 ("drm/amd/display: add DCN32/321 specific files for Display Core") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/4470 Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Signed-off-by: James Lin <pinglei.lin@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11) Cc: stable@vger.kernel.org
2026-05-11drm/amdgpu: fix userq hang detection and resetChristian König
Fix lock inversions pointed out by Prike and Sunil. The hang detection timeout *CAN'T* grab locks under which we wait for fences, especially not the userq_mutex lock. Then instead of this completely broken handling with the hang_detect_fence just cancel the work when fences are processed and re-start if necessary. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 1b62077f045ac6ffde7c97005c6659569ac5c1ec)
2026-05-11drm/amdgpu: remove almost all calls to amdgpu_userq_detect_and_reset_queuesChristian König
Well the reset handling seems broken on multiple levels. As first step of fixing this remove most calls to the hang detection. That function should only be called after we run into a timeout! And *NOT* as random check spread over the code in multiple places. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 71bea36b54ccfb14cbc90f94267af6369af4e702)
2026-05-11drm/amdgpu: rework amdgpu_userq_signal_ioctl v3Christian König
This one was fortunately not looking so bad as the wait ioctl path, but there were still a few things which could be fixed/improved: 1. Allocating with GFP_ATOMIC was quite unnecessary, we can do that before taking the userq_lock. 2. Use a new mutex as protection for the fence_drv_xa so that we can do memory allocations while holding it. 3. Starting the reset timer is unnecessary when the fence is already signaled when we create it. 4. Cleanup error handling, avoid trying to free the queue when we don't even got one. v2: fix incorrect usage of xa_find, destroy the new mutex on error v3: cleanup ref ordering Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 1609eb0f81a609d350169839128cecf298c84e7a)
2026-05-11drm/amdgpu: remove deadlocks from amdgpu_userq_pre_resetChristian König
The purpose of a GPU reset is to make sure that fence can be signaled again and the signal and resume workers can make progress again. So waiting for the resume worker or any fence in the GPU reset path is just utterly nonsense. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Prike Liang <Prike.Liang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit fcd5f065eab46993af43442fd77ee8d9eb9c5bdf)
generated by cgit v1.2.3 (git 2.25.1) at 2026-07-19 12:52:53 +0000