summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-06-13batman-adv: ensure bcast is writable before modifying TTLSven Eckelmann
Before batman-adv is allowed to write to an skb, it either has to have its own copy of the skb or used skb_cow() to ensure that the data part is not shared. The old implementation used a shared queue and created copies before attempting to write to it. But with the new implementation, the broadcast packet is already modified when it gets received. Potentially writing to shared buffers in this process. Adding a skb_cow() right before this operation avoids this and can at the same time prepare it for the modifications required to rebroadcast the packet. Cc: stable@kernel.org Fixes: 3f69339068f9 ("batman-adv: bcast: queue per interface, if needed") Signed-off-by: Sven Eckelmann <sven@narfation.org>
2026-06-13batman-adv: gw: don't deselect gateway with active hardifSven Eckelmann
The batadv_hardif_cnt() was previously checking if there is an batadv_hard_iface->mesh_iface which is has the same mesh_iface. And since batadv_hardif_disable_interface() was resetting the batadv_hard_iface->mesh_iface after this check, it had to verify whether *1* interface was still part of the mesh_iface before it started the gateway deselection. But after batadv_hardif_cnt() is now checking the lower interfaces of mesh_iface and batadv_hardif_disable_interface() already removed the interface via netdev_upper_dev_unlink() earlier in this function, the check must now make sure that *0* interfaces can be found by batadv_hardif_cnt() before selected gateway must be deselected. Otherwise the deselection would already happen one batadv_hard_iface too early. Because a 0 hardif count from batadv_hardif_cnt() is equal to an empty list, it is possible to replace the counting with a simple list_empty(). Cc: stable@kernel.org Fixes: 7dc284702bcd ("batman-adv: store hard_iface as iflink private data") Reviewed-by: Nora Schiffer <neocturne@universe-factory.net> Signed-off-by: Sven Eckelmann <sven@narfation.org>
2026-06-12selftests/bpf: Add arena direct-value one-past-end reject testWoojin Ji
BPF_MAP_TYPE_ARENA supports direct-value pseudo loads, but unlike array maps its map value_size is zero and the valid direct-value range is the arena mmap size, max_entries * PAGE_SIZE. Commit 3ac1a467e376 ("bpf: Fix off-by-one boundary validation in arena direct-value access") fixed arena_map_direct_value_addr() to reject an offset exactly at the end of the arena mapping. Add a regression test that loads a BPF_PSEUDO_MAP_VALUE with off == arena_size and verifies that the verifier rejects it with the expected offset in the log. This is intentionally kept as a userspace raw-instruction test. I tried expressing the same BPF_PSEUDO_MAP_VALUE + off == arena_size case in verifier_arena.c with inline assembly. The only form that produces the desired instruction bytes uses __imm_addr(arena), but that emits R_BPF_64_NODYLD32, which the libbpf/bpftool link step rejects. Other register, immediate, and memory constraints either fail in the BPF backend or lower to a normal R_BPF_64_64 load followed by an ALU add, which does not exercise arena_map_direct_value_addr() with the boundary offset in the second ldimm64 slot. A legacy test_verifier fixture can express the raw instruction directly, but it needs arena map creation, mmap, and fixup plumbing in the legacy runner. That is more intrusive than the small prog_tests raw-instruction test. Use the userspace raw-instruction test, following the existing selftests pattern used for direct map-value pseudo loads, so insns[1].imm can be set to arena_size precisely. Assisted-by: ChatGPT:gpt-5.5 Signed-off-by: Woojin Ji <random6.xyz@gmail.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Cc: Emil Tsalapatis <emil@etsalapatis.com> Cc: Junyoung Jang <graypanda.inzag@gmail.com> Link: https://lore.kernel.org/r/20260612-arena-direct-value-v1-v4-1-b81b642f5277@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-12rqspinlock: Fix order in raw_res_spin_(un)lock_irq to allow scheduleGabriele Monaco
raw_res_spin_unlock_irqrestore() calls raw_res_spin_unlock() and then restores interrupts, this means preemption is enabled when interrupts are still disabled (as part of raw_res_spin_unlock()) so this cannot trigger an actual preemption. This is inconsistent with other spinlock implementations (raw_spin_unlock_irqrestore() and bpf_res_spin_unlock_irqrestore() itself). Adjust the macro to ensure interrupts are enabled before enabling preemption, allowing to schedule at that point. Make the same modification in the error path of raw_res_spin_lock_irqsave(). Fixes: 101acd2e78b1 ("rqspinlock: Add macros for rqspinlock usage") Cc: stable@vger.kernel.org Acked-by: Arnd Bergmann <arnd@arndb.de> # asm-generic Acked-by: Waiman Long <longman@redhat.com> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com> Link: https://lore.kernel.org/r/20260610090431.32427-1-gmonaco@redhat.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-12Merge branch ↵Alexei Starovoitov
'bpf-fix-setting-retval-to-eperm-for-cgroup-hooks-not-returning-errno' Xu Kuohai says: ==================== bpf: Fix setting retval to -EPERM for cgroup hooks not returning errno This series fixes the issue reported by sashiko in [1]. The issue is that, when a cgroup BPF program exits with 0, bpf_prog_run_array_cg() sets the hook return value to -EPERM if it is not a valid errno. This is correct for errno-based hooks, which return 0 on success and negative errno on failure, but wrong for void and boolean LSM hooks. Boolean LSM hooks should only return true or false, and void LSM hooks have no return value at all. Fix it by skipping setting -EPERM for hooks not returning errno. [1] https://lore.kernel.org/bpf/20260605144232.95A141F00893@smtp.kernel.org/ ==================== Link: https://patch.msgid.link/20260610201724.733943-1-xukuohai@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-12selftests/bpf: Add retval test for bool and errno LSM cgroup hooksXu Kuohai
Add test to check the return value when a BPF program exits with 0 for a boolean and an errno LSM hook. For each hook, two BPF programs are attached. The first program returns 0 without calling bpf_set_retval() to exercise the return value translation logic, while the second program reads the retval via bpf_get_retval(). Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/r/20260610201724.733943-3-xukuohai@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-12bpf: Fix setting retval to -EPERM for cgroup hooks not returning errnoXu Kuohai
When a cgroup BPF program exits with 0, bpf_prog_run_array_cg() sets the hook return value to -EPERM if it is not a valid errno. This is correct for errno-based hooks, which return 0 on success and negative errno on failure, but wrong for boolean and void LSM hooks. Boolean LSM hooks should only return true or false, and void LSM hooks have no return value at all. Fix it by skipping setting -EPERM for hooks not returning errno. Fixes: 69fd337a975c ("bpf: per-cgroup lsm flavor") Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/r/20260610201724.733943-2-xukuohai@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-13firewire: core: Open-code topology list walkKaitao Cheng
A later change will make list_for_each_entry() cache the next element before entering the loop body. for_each_fw_node() intentionally appends newly discovered child nodes to the temporary walk list while the list is being traversed. Keep the loop open-coded so the next node is looked up only after children have been appended. This preserves the current breadth-first traversal semantics and prepares the code for the list iterator update. Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn> Link: https://lore.kernel.org/r/20260609061347.93688-3-kaitao.cheng@linux.dev Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2026-06-12net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post()Michael Bommarito
qrtr_endpoint_post() validates an incoming packet with if (!size || len != ALIGN(size, 4) + hdrlen) goto err; where size comes from the wire. On 32-bit, size_t is 32 bits and ALIGN(size, 4) wraps to 0 for size >= 0xfffffffd, so the check passes and skb_put_data(skb, data + hdrlen, size) writes past the hdrlen-sized skb and oopses the kernel. 64-bit is unaffected. This is the 32-bit residual of ad9d24c9429e2 ("net: qrtr: fix OOB Read in qrtr_endpoint_post"), which fixed only the 64-bit case. Reject any size that cannot fit the buffer before the ALIGN. Fixes: ad9d24c9429e2 ("net: qrtr: fix OOB Read in qrtr_endpoint_post") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260611125455.2352279-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net/mlx5: Check max_macs devlink param value against max capabilityDragos Tatulea
The max_macs devlink param is checked against the FW max value only at param register time (driver load) and inside the validate callback (devlink param set). The stored DRIVERINIT value persists across FW resets and devlink reloads without any further checks against the max. If the FW link type changes from Ethernet to IB and a FW reset happens, the MAX cap for log_max_current_uc_list will become zero, but the previously stored max_macs value remains and is unconditionally programmed into the HCA caps in handle_hca_cap(). FW will then return a syndrome during SET_HCA_CAP: mlx5_cmd_out_err:839:(pid 3831): SET_HCA_CAP(0x109) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0x537801), err(-22) set_hca_cap:907:(pid 3831): handle_hca_cap failed This results in a failure to register the RDMA device. This patch skips programming log_max_current_uc_list when the MAX capability is 0 (in case of IB). Fixes: 8680a60fc1fc ("net/mlx5: Let user configure max_macs generic param") Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Yael Chemla <ychemla@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Link: https://patch.msgid.link/20260611135230.534513-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge branch 'psp-add-support-for-dev-assoc-disassoc'Jakub Kicinski
Wei Wang says: ==================== psp: Add support for dev-assoc/disassoc The main purpose of this feature is to associate virtual devices like veth or netkit with a real PSP device, so we could provide PSP functionality to the application running with virtual devices. A typical deployment that works with this feature is as follows: Host Namespace: psp_dev_local ←──physically linked──→ psp_dev_peer (PSP device) │ │ BPF on psp_dev_local ingress: bpf_redirect_peer() to nk_guest │ nk_host / veth_host │ │ BPF on nk_host ingress: bpf_redirect_neigh() to psp_dev_local │ Guest Namespace (netns): │ nk_guest / veth_guest ★ PSP application run here Remote Namespace (_netns): psp_dev_peer ★ PSP server application runs here Note: The general requirement for this feature to work: For PSP to work correctly, the egress device at validate_xmit_skb() time must have psp_dev matching the association's psd. Any device stacking or traffic redirection that changes the egress device will cause either: 1. TX validation failure (SKB_DROP_REASON_PSP_OUTPUT) - fail-safe 2. RX policy failure after tx-assoc - packets without PSP extension are rejected by receiver expecting encrypted traffic Here are a few examples that this feature would not work: - Bonding with load balancing in round-robin, XOR, 802.3ad mode across multiple PSP devices, or mixed PSP and non-PSP devices - Bonding with active-backup mode might work without PSP migration for failover case. - ipvlan/macvlan in bridge mode would not work given packets are loopbacked locally without going through the PSP device. ==================== Link: https://patch.msgid.link/20260608233118.2694144-1-weibunny.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests/net: psp: add dev-get, no-nsid, and cleanup testsWei Wang
Add the following 3 tests: - _psp_dev_get_check_netkit_psp_assoc: verifies dev-get output in both host and guest namespaces, checking assoc-list, by-association flag, and nsid values - _dev_assoc_no_nsid: tests dev-assoc and dev-disassoc without the nsid attribute, verifying ifindex lookup in the caller's namespace - _psp_dev_assoc_cleanup_on_netkit_del: verifies that deleting the associated netkit interface properly cleans up the assoc-list, using a disposable netkit pair to avoid disturbing the shared environment Signed-off-by: Wei Wang <weibunny@fb.com> Link: https://patch.msgid.link/20260608233118.2694144-11-weibunny.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests/net: psp: add cross-namespace notification testsWei Wang
Add tests that verify PSP notifications are delivered to listeners in associated namespaces: - _key_rotation_notify_multi_ns_netkit: triggers key rotation and verifies the notification is received in both main and guest namespaces - _dev_change_notify_multi_ns_netkit: triggers dev_set and verifies the dev_change notification is received in both namespaces Signed-off-by: Wei Wang <weibunny@fb.com> Link: https://patch.msgid.link/20260608233118.2694144-10-weibunny.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests/net: psp: add dev-assoc data path testWei Wang
Add _assoc_check_list() test that associates nk_guest with the PSP device and verifies the assoc-list is correctly populated. Add _data_basic_send_netkit_psp_assoc() which tests PSP data send through a netkit interface associated with a PSP device. The test associates nk_guest with the PSP device, then sends PSP-encrypted traffic from the guest namespace. Signed-off-by: Wei Wang <weibunny@fb.com> Link: https://patch.msgid.link/20260608233118.2694144-9-weibunny.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests/net: psp: support PSP in NetDrvContEnv infrastructureWei Wang
Add infrastructure to support PSP tests across network namespaces using NetDrvContEnv with netkit pairs. This enables testing PSP device association, where a non-PSP-capable device (e.g. netkit) in a guest namespace is associated with a real PSP device in the host namespace, allowing the guest to perform PSP encryption/decryption through the host's PSP hardware. The topology is: Host NS: psp_dev_local <---> nk_host | | | | (netkit pair) | | Remote NS: psp_dev_peer Guest NS: nk_guest (responder) (PSP tests) env.py: - nk_guest_ifindex is queried after moving the device into the guest namespace, so tests can use it directly for dev-assoc psp.py: - PSP device lookup supports container environments where the PSP device is on the physical interface, not the test interface - Association helpers handle dev-assoc/dev-disassoc with defer-based cleanup to prevent state leaks on test assertion failures - main() tries NetDrvContEnv with primary_rx_redirect and falls back to NetDrvEpEnv, so existing tests continue to work without the container environment Signed-off-by: Wei Wang <weibunny@fb.com> Link: https://patch.msgid.link/20260608233118.2694144-8-weibunny.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests/net: rename _nk_host_ifname to nk_host_ifnameWei Wang
Rename _nk_host_ifname to nk_host_ifname in NetDrvContEnv to make it a public attribute, matching the nk_guest_ifname rename. Tests that access the host-side netkit interface name (e.g. for cleanup after deleting the netkit pair) no longer trigger pylint protected-access warnings. Signed-off-by: Wei Wang <weibunny@fb.com> Link: https://patch.msgid.link/20260608233118.2694144-7-weibunny.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests/net: add _find_bpf_obj() to search hw/ for BPF objectsWei Wang
Add _find_bpf_obj() helper to NetDrvContEnv that searches the test directory first, then falls back to the hw/ subdirectory. This allows tests outside drivers/net/hw/ (e.g. psp.py in drivers/net/) to find BPF objects built in the hw/ directory. Update _attach_bpf() and _attach_primary_rx_redirect_bpf() to use _find_bpf_obj() for BPF object discovery. Signed-off-by: Wei Wang <weibunny@fb.com> Link: https://patch.msgid.link/20260608233118.2694144-6-weibunny.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests/net: psp: refactor test builders to use ksft_variantsWei Wang
Replace the manual psp_ip_ver_test_builder() and ipver_test_builder() functions with @ksft_variants decorators for data_basic_send and data_mss_adjust. This is a pure refactor with no behavior change. Signed-off-by: Wei Wang <weibunny@fb.com> Link: https://patch.msgid.link/20260608233118.2694144-5-weibunny.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12psp: add a new netdev event for dev unregisterWei Wang
Add a new netdev event for dev unregister and handle the removal of this dev from psp->assoc_dev_list, upon the first dev-assoc operation. Signed-off-by: Wei Wang <weibunny@fb.com> Reviewed-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20260608233118.2694144-4-weibunny.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12psp: add new netlink cmd for dev-assoc and dev-disassocWei Wang
The main purpose of this cmd is to be able to associate a non-psp-capable device (e.g. veth or netkit) with a psp device. One use case is if we create a pair of veth/netkit, and assign 1 end inside a netns, while leaving the other end within the default netns, with a real PSP device, e.g. netdevsim or a physical PSP-capable NIC. With this command, we could associate the veth/netkit inside the netns with PSP device, so the virtual device could act as PSP-capable device to initiate PSP connections, and performs PSP encryption/decryption on the real PSP device. Signed-off-by: Wei Wang <weibunny@fb.com> Reviewed-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20260608233118.2694144-3-weibunny.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12psp: add admin/non-admin version of psp_device_get_lockedWei Wang
Introduce 2 versions of psp_device_get_locked: 1. psp_device_get_locked_admin(): This version is used for operations that would change the status of the psd, and are currently used for dev-set and key-rotation. 2. psp_device_get_locked(): This is the non-admin version, which are used for broader user issued operations including: dev-get, rx-assoc, tx-assoc, get-stats. Following commit will be implementing both of the checks. Signed-off-by: Wei Wang <weibunny@fb.com> Reviewed-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20260608233118.2694144-2-weibunny.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge branch 'bpf-fix-generic-devmap-egress-skb-sharing'Alexei Starovoitov
Sun Jian says: ==================== bpf: Fix generic devmap egress skb sharing Generic XDP devmap multi redirect can leave cloned skbs sharing packet data. When a devmap egress program mutates packet data, another destination sharing the same data may observe that mutation. Fix this by making cloned skbs private before running the generic devmap egress program. The private copy is made in dev_map_generic_redirect() so dev_map_bpf_prog_run_skb() can keep returning the XDP action directly. Add selftest coverage for the last-destination case, where the final destination runs on the original skb while earlier destinations use cloned skbs. The test records the source MAC observed by an earlier destination and checks that it is neither the sentinel value left in the result map nor the MAC written by the final destination. --- v5: - Move the skb_copy() check back to dev_map_generic_redirect() to keep dev_map_bpf_prog_run_skb() returning only the XDP action. - Preserve mac_len after skb_copy(). - Use __be64 temporary values when updating mac_map from userspace. - Initialize rx_mac with a sentinel in the last-destination test instead of relying on -ENOENT for ARRAY map lookups. - Adjust the last-destination test topology so the checked earlier destination is not the ingress/source veth. - Split the last-destination check into two assertions: one for store_mac_1 updating rx_mac and one for detecting last-destination rewrite leakage. v4: https://lore.kernel.org/bpf/20260611080850.536996-1-sun.jian.kdev@gmail.com/T/#mf830f03d362f33e0941d1b0e425169698fce76e5 - Preserve mac_len after skb_copy(). - Separate errno return from XDP action output in dev_map_bpf_prog_run_skb(). - Zero-initialize net_config in the new selftest. v3: https://lore.kernel.org/bpf/20260611043317.512843-1-sun.jian.kdev@gmail.com/ - Split the kernel fix and selftest into separate patches. - Move the private-copy logic into dev_map_bpf_prog_run_skb(). - Use deterministic DEVMAP_HASH keys in the last-destination selftest. - Fix the Fixes tag. v2: https://lore.kernel.org/bpf/08c35c70-a59e-4e0e-91db-22b5ec30b611@linux.dev/ - Move the private-copy step into dev_map_generic_redirect() so the last-destination path is covered as well. - Use skb_copy() instead of skb_unshare() to keep caller ownership unchanged on allocation failure. - Add a generic XDP last-destination selftest case. v1: https://lore.kernel.org/bpf/CABFUUZFimdrZdq=NWi+N-0sJZWvMwY=f4iF6-3TVMS8=m07Zmw@mail.gmail.com/ ==================== Link: https://patch.msgid.link/20260612114032.244616-1-sun.jian.kdev@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-12selftests/bpf: Cover generic devmap egress last-dst rewriteSun Jian
Strengthen xdp_veth_egress to check that each destination observes the MAC selected for its own egress ifindex, instead of only checking that the observed MAC differs from a single magic value. Add a generic XDP last-destination test where an earlier destination does not have a devmap egress program while the final destination does. This covers the case where the final destination runs on the original skb and could otherwise rewrite packet data still shared with an earlier cloned skb. Use deterministic DEVMAP_HASH keys for the egress map so the intended last destination is stable. Initialize the result map with a sentinel value and check that store_mac_1 overwrites it before checking that the earlier destination did not observe the MAC written by the final destination. Suggested-by: Jiayuan Chen <jiayuan.chen@linux.dev> Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com> Link: https://lore.kernel.org/r/20260612114032.244616-3-sun.jian.kdev@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-12bpf: Run generic devmap egress prog on private skbSun Jian
Generic XDP devmap multi redirect uses skb_clone() for intermediate destinations and sends the last destination with the original skb. This can leave multiple destinations sharing the same packet data. This becomes visible after generic devmap egress-program support was added: a devmap egress program may mutate packet data, and another destination sharing the same data can observe that mutation. Native XDP broadcast redirect does not have this issue because xdpf_clone() copies the frame data for each destination. Generic XDP should provide the same per-destination isolation before running a devmap egress program. Fix this by making cloned skbs private before running the generic devmap egress program. Use skb_copy() instead of skb_unshare() so allocation failure does not consume the skb and the existing caller error paths keep their ownership semantics. Fixes: 2ea5eabaf04a ("bpf: devmap: Implement devmap prog execution for generic XDP") Suggested-by: Jiayuan Chen <jiayuan.chen@linux.dev> Suggested-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com> Link: https://lore.kernel.org/r/20260612114032.244616-2-sun.jian.kdev@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-12Merge branch 'net-dsa-microchip-remove-unnecessary-dsa_switch_ops-callbacks'Jakub Kicinski
Bastien Curutchet says: ==================== net: dsa: microchip: remove unnecessary dsa_switch_ops callbacks This series continues the rework of the KSZ driver initiated by two previous series (see [1] & [2]). The KSZ driver handles more than 20 switches split in several families. This was previously handled through a common set of dsa_switch_ops operations that used device-specific ksz_dev_ops callbacks. The two previous series have split this common struct dsa_switch_ops into 5 to connect the ksz_dev_ops's implentations directly to the new dsa_swicth ops. This series continues in the same vein and removes the dsa_switch_ops operations that aren't used. On top of this on-going rework I added PTP and periodic output support for the KSZ8463 (which was my first goal). There are still more than 20 patches left for all this so this series will be followed by three others and if you want to see the full picture we can check my github ([3]). FYI, I only have a KSZ8463 so, unfortunately, I can't test other switches. The next series is going to move out of ksz_common.c the last remaining functions that aren't truly common to all KSZ switches. The series after that will add PTP support for the KSZ8463 and the final one will add periodic output support for the KSZ8463. [1]: https://lore.kernel.org/r/20260505-clean-ksz-driver-v1-0-05d70fa42461@bootlin.com [2]: https://lore.kernel.org/r/20260521-clean-ksz-2nd-series-v3-0-75c38971c19a@bootlin.com [3]: https://github.com/bastien-curutchet/linux/tree/ksz_rework ==================== Link: https://patch.msgid.link/20260608-clean-ksz-3rd-v2-0-6e61b7be23c4@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: dsa: microchip: implement port_teardown only if neededBastien Curutchet (Schneider Electric)
The port_teardown() operation is optional. Yet, it is implemented by all the KSZ switches through a common function that doesn't do anything for the switches that aren't part of the ksz9477 family Remove the implementation from the switches that don't need it. Implement instead a ksz9477-specific port_teardown. Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260608-clean-ksz-3rd-v2-10-6e61b7be23c4@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: dsa: microchip: implement lan937x-specific MDIO registrationBastien Curutchet (Schneider Electric)
All the switches use a common mdio_register() function that uses two ksz_dev_ops callbacks (.mdio_bus_preinit() and .create_phy_addr_map()) to handle the lan937x specific case. These two callbacks are used only at this place in the code. Implement a new lan937x-specific MDIO registration functions that uses these two lan937x-specific functions. The lan937x bindings don't have any 'interrupts' property so this lan937x_mdio_register() doesn't call ksz_irq_phy_setup(). Expose the common ksz_*_mdio_{read/write} functions so they can be used in lan937x.c Remove the callbacks from ksz_dev_ops. Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260608-clean-ksz-3rd-v2-9-6e61b7be23c4@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: dsa: microchip: implement port_hsr_join for KSZ9477 onlyBastien Curutchet (Schneider Electric)
All switches implement the optional .port_hsr_join operation while only the KSZ9477 truly supports it. Remove the common port_hsr_join implementation. Replace it with a specific implementation for the KSZ9477 case. Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260608-clean-ksz-3rd-v2-8-6e61b7be23c4@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: dsa: microchip: implement .{get/set}_wol only if neededBastien Curutchet (Schneider Electric)
All the KSZ switches use common {get/set}_wol operations while only the ksz9477 and the ksz87xx families really support it. These operations are optional so there is no point implementing them to return -EOPNOTSUPP. Remove the {get/set}_wol callbacks from the switch operations for the ksz88xx, the ksz8463 and the lan937x families. Remove the family check from the common {get/set}_wol implementation. Note that is_ksz9477() is only true for the KSZ9477 so this change will also add WoL support for the other switches using the ksz9477_switch_ops. I checked their datasheet, they implement the same PME_WOL registers, at the same addresses, so this should go fine. Modify the ksz_wol_pre_shutdown() initial check to ensure consistency in the WoL handling for these non-KSZ9477 switches using ksz9477_switch_ops. Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260608-clean-ksz-3rd-v2-7-6e61b7be23c4@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: dsa: microchip: implement .support_eee() only if neededBastien Curutchet (Schneider Electric)
The .support_eee() operation is optional. Yet, it is implemented by the KSZ switches through a common functon that reports false for every chip except for KSZ8563, KSZ9563 and KSZ9893 from the KSZ9477 family. Remove the implementation from the switches that don't support EEE. Also remove .set_mac_eee() for them as .set_mac_eee() is gated by the `support_eee` presence in the core. Implement instead a ksz9477-specific support_eee for these three supported switches. Note that comment /* KSZ879x/KSZ877x/KSZ876x Errata DS80000687C Module 2 */ is completely removed because it concerns the KSZ87xx family that doesn't support at all EEE. Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260608-clean-ksz-3rd-v2-6-6e61b7be23c4@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: dsa: microchip: remove setup_rgmii_delay() KSZ operationBastien Curutchet (Schneider Electric)
setup_rgmii_delay() operation is only used once during the common phylink MAC configuration. Only the lan937x switch implements this setup_rgmii_delay(). Remove the setup_rgmii_delay operation from ksz_dev_ops. Implement a lan937x-specific phylink MAC configuration that does this RGMII delay setup. Export ksz_set_xmii since it's needed by the lan937x implementation. Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260608-clean-ksz-3rd-v2-5-6e61b7be23c4@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: dsa: microchip: wrap the MAC configuration checks in a functionBastien Curutchet (Schneider Electric)
The common .mac_config() implementation checks some conditions before doing any register access. As this common implementation is about to be split in the upcoming patch, these checks would lead to code duplication. Wrap all the checks in a need_config() function that returns true when the driver really need to access the switch registers to configure the MAC. Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260608-clean-ksz-3rd-v2-4-6e61b7be23c4@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: dsa: microchip: implement get_phy_flags only if neededBastien Curutchet (Schneider Electric)
The common ksz_get_phy_flags() is used by all the switches to implement the optional .get_phy_flags DSA operation. It always returns 0 except for KSZ88X3 switches where an errata has to be handled. Make ksz_get_phy_flags() ksz88xx-specific. Remove the get_phy_flags implementation for the switches that don't need it. Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260608-clean-ksz-3rd-v2-3-6e61b7be23c4@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: dsa: microchip: remove VLAN operations for ksz8463Vladimir Oltean
KSZ8463 uses the common KSZ8 implementation for its VLAN operations. This implementation returns -ENOTSUPP for the KSZ8463 case, which is pointless. Remove the VLAN operations from the ksz8463_switch_ops so the core can directly return -ENOTSUPP. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260608-clean-ksz-3rd-v2-2-6e61b7be23c4@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: dsa: microchip: remove useless common cls_flower_{add/del} operationsBastien Curutchet (Schneider Electric)
All the KSZ switches share a common implementation of the cls_flower_{add/del} operations. These common implementations return ksz9477-specific implementations for the KSZ9477 family and -EOPNOTSUPP for the others. -EOPNOTSUPP is already returned by the DSA core when the operation isn't implemented. Remove the common implementations. Directly link the ksz9477_cls_flower_{add/del}() to the KSZ9477 callback. Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260608-clean-ksz-3rd-v2-1-6e61b7be23c4@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge branch 'net-bridge-take-care-of-p-flags-accesses'Jakub Kicinski
Eric Dumazet says: ==================== net: bridge: take care of p->flags accesses (struct net_bridge_port)->flags can be read/written locklessly, and thus can fire KCSAN warnings, or real bugs. Prefer atomic operations (test_bit(), clear_bit(), set_bit()) and use READ_ONCE() for the remaining uses. ==================== Link: https://patch.msgid.link/20260611203453.3067462-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: bridge: use atomic ops to read/change p->flags (III)Eric Dumazet
Use test_bit(), clear_bit(), set_bit() in: net/bridge/br_multicast.c net/bridge/br_netlink.c net/bridge/br_stp.c net/bridge/br_stp_bpdu.c net/bridge/br_switchdev.c net/bridge/br_vlan_options.c Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20260611203453.3067462-6-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: bridge: use atomic ops to read/change p->flags (II)Eric Dumazet
Use READ_ONCE(p->flags) in br_port_flag_is_set() to keep its ABI. Use test_bit(), clear_bit(), set_bit() in: net/bridge/br_input.c net/bridge/br_mrp.c net/bridge/br_mrp_netlink.c Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20260611203453.3067462-5-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: bridge: use atomic ops to read/change p->flags (I)Eric Dumazet
Use test_bit() in net/bridge/br_arp_nd_proxy.c, net/bridge/br_fdb.c and net/bridge/br_forward.c. Use READ_ONCE(p->flags) in br_recalculate_neigh_suppress_enabled() as we test two bits at once. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20260611203453.3067462-4-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12bridge: use atomic ops to read/change p->flags in br_netlink.cEric Dumazet
Change net/bridge/br_netlink.c to use atomic operations to read/change bits in p->flags. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20260611203453.3067462-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12bridge: use atomic ops to read/change p->flags in sysfsEric Dumazet
Change net/bridge/br_sysfs_if.c to use atomic operations to read/change bits in p->flags. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20260611203453.3067462-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net/sched: sch_dualpi2: Add missing module aliasVictor Nogueira
When a qdisc is added by name, the kernel tries to autoload its module via request_qdisc_module(), which calls: request_module(NET_SCH_ALIAS_PREFIX "%s", name); i.e. it asks modprobe to resolve the "net-sch-<kind>" alias (e.g. "net-sch-dualpi2") rather than the module's file name. Since dualpi2 was shipped without this alias, the autoload fails: tc qdisc add dev lo root handle 1: dualpi2 Error: Specified qdisc kind is unknown. Fix this by adding the missing alias so the qdisc is autoloaded on demand like the others. Fixes: 320d031ad6e4 ("sched: Struct definition and parsing of dualpi2 qdisc") Signed-off-by: Victor Nogueira <victor@mojatatu.com> Reviewed-by: Pedro Tammela <pctammela@mojatatu.com> Link: https://patch.msgid.link/20260611205849.3287640-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12docs: networking: add guidance on what to push via extackJakub Kicinski
Every now and then someone tries to duplicated extack messages to dmesg. Document our guidance against this. Also indicate that system level faults should continue to go to system logs. The high level thinking is to try to distinguish between what's important to the user vs system admin. Reviewed-by: Joe Damato <joe@dama.to> Link: https://patch.msgid.link/20260611172149.1877704-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12ptp: ocp: add shutdown callbackVadim Fedorenko
The shutdown callback was never implemented for this driver, but it's needed because .remove() callback is never called during kexec/reboot process. That leaves HW with some interrupts enabled and may cause spurious interrupt while booting into a new kernel during with kexec. If it happens that I2C interrupt fires during kexec, the whole I2C bus is disabled leaving TimeCard with no devlink communication. The same happens if timestampers were enabled, leaving the card without timestamper interrupts until full reboot cycle. Implement .shutdown() callback with the same function as remove callback. Signed-off-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260611190333.787132-1-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge branch ↵Jakub Kicinski
'ipv6-honor-oif-when-choosing-nexthop-for-locally-generated-traffic' Ido Schimmel says: ==================== ipv6: Honor oif when choosing nexthop for locally generated traffic Patch #1 is a preparation patch following the comment from Sashiko on v2. See details in the commit message. Patch #2 aligns IPv6 with IPv4 and changes IPv6 route lookup to prefer a nexthop whose nexthop device matches the specified oif. Patch #3 adds a selftest. ==================== Link: https://patch.msgid.link/20260611154605.992528-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests: fib_tests: Add test cases for route lookup with oifIdo Schimmel
Test that both address families respect the oif parameter when a matching multipath route is found, regardless of the presence of a source address. Output without "ipv6: Select best matching nexthop object in fib6_table_lookup()" and "ipv6: Honor oif when choosing nexthop for locally generated traffic": # ./fib_tests.sh -t "ipv4_mpath_oif ipv4_mpath_oif_nh ipv4_mpath_oif_vrf ipv6_mpath_oif ipv6_mpath_oif_nh ipv6_mpath_oif_vrf" IPv4 multipath oif test TEST: IPv4 multipath via first nexthop [ OK ] TEST: IPv4 multipath via second nexthop [ OK ] TEST: IPv4 multipath via first nexthop with source address [ OK ] TEST: IPv4 multipath via second nexthop with source address [ OK ] IPv4 multipath oif with nexthop object test TEST: IPv4 multipath via first nexthop [ OK ] TEST: IPv4 multipath via second nexthop [ OK ] TEST: IPv4 multipath via first nexthop with source address [ OK ] TEST: IPv4 multipath via second nexthop with source address [ OK ] IPv4 multipath oif with VRF test TEST: IPv4 multipath via first nexthop [ OK ] TEST: IPv4 multipath via second nexthop [ OK ] TEST: IPv4 multipath via first nexthop with source address [ OK ] TEST: IPv4 multipath via second nexthop with source address [ OK ] IPv6 multipath oif test TEST: IPv6 multipath via first nexthop [ OK ] TEST: IPv6 multipath via second nexthop [ OK ] TEST: IPv6 multipath via first nexthop with source address [FAIL] TEST: IPv6 multipath via second nexthop with source address [FAIL] IPv6 multipath oif with nexthop object test TEST: IPv6 multipath via first nexthop [FAIL] TEST: IPv6 multipath via second nexthop [FAIL] TEST: IPv6 multipath via first nexthop with source address [FAIL] TEST: IPv6 multipath via second nexthop with source address [FAIL] IPv6 multipath oif with VRF test TEST: IPv6 multipath via first nexthop [ OK ] TEST: IPv6 multipath via second nexthop [ OK ] TEST: IPv6 multipath via first nexthop with source address [FAIL] TEST: IPv6 multipath via second nexthop with source address [FAIL] Tests passed: 16 Tests failed: 8 Output with the patches: # ./fib_tests.sh -t "ipv4_mpath_oif ipv4_mpath_oif_nh ipv4_mpath_oif_vrf ipv6_mpath_oif ipv6_mpath_oif_nh ipv6_mpath_oif_vrf" IPv4 multipath oif test TEST: IPv4 multipath via first nexthop [ OK ] TEST: IPv4 multipath via second nexthop [ OK ] TEST: IPv4 multipath via first nexthop with source address [ OK ] TEST: IPv4 multipath via second nexthop with source address [ OK ] IPv4 multipath oif with nexthop object test TEST: IPv4 multipath via first nexthop [ OK ] TEST: IPv4 multipath via second nexthop [ OK ] TEST: IPv4 multipath via first nexthop with source address [ OK ] TEST: IPv4 multipath via second nexthop with source address [ OK ] IPv4 multipath oif with VRF test TEST: IPv4 multipath via first nexthop [ OK ] TEST: IPv4 multipath via second nexthop [ OK ] TEST: IPv4 multipath via first nexthop with source address [ OK ] TEST: IPv4 multipath via second nexthop with source address [ OK ] IPv6 multipath oif test TEST: IPv6 multipath via first nexthop [ OK ] TEST: IPv6 multipath via second nexthop [ OK ] TEST: IPv6 multipath via first nexthop with source address [ OK ] TEST: IPv6 multipath via second nexthop with source address [ OK ] IPv6 multipath oif with nexthop object test TEST: IPv6 multipath via first nexthop [ OK ] TEST: IPv6 multipath via second nexthop [ OK ] TEST: IPv6 multipath via first nexthop with source address [ OK ] TEST: IPv6 multipath via second nexthop with source address [ OK ] IPv6 multipath oif with VRF test TEST: IPv6 multipath via first nexthop [ OK ] TEST: IPv6 multipath via second nexthop [ OK ] TEST: IPv6 multipath via first nexthop with source address [ OK ] TEST: IPv6 multipath via second nexthop with source address [ OK ] Tests passed: 24 Tests failed: 0 Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20260611154605.992528-4-idosch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12ipv6: Honor oif when choosing nexthop for locally generated trafficIdo Schimmel
Commit 741a11d9e410 ("net: ipv6: Add RT6_LOOKUP_F_IFACE flag if oif is set") made the kernel honor the oif parameter when specified as part of output route lookup: # ip route add 2001:db8:1::/64 dev dummy1 # ip route add ::/0 dev dummy2 # ip route get 2001:db8:1::1 oif dummy2 fibmatch default dev dummy2 metric 1024 pref medium Due to regression reports, the behavior was partially reverted in commit d46a9d678e4c ("net: ipv6: Dont add RT6_LOOKUP_F_IFACE flag if saddr set") to only honor the oif if source address is not specified: # ip route get 2001:db8:1::1 from 2001:db8:2::1 oif dummy2 fibmatch 2001:db8:1::/64 dev dummy1 metric 1024 pref medium That is, when source address is specified, the kernel will choose the most specific route even if its nexthop device does not match the specified oif. This creates a problem for multipath routes. After looking up a route, when source address is not specified, the kernel will choose a nexthop whose nexthop device matches the specified oif: # sysctl -wq net.ipv6.conf.all.forwarding=1 # ip route add 2001:db8:10::/64 nexthop via fe80::1 dev dummy1 nexthop via fe80::2 dev dummy2 # for i in {1..100}; do ip route get 2001:db8:10::${i} oif dummy2; done | grep -o dummy[0-9] | sort | uniq -c 100 dummy2 But will disregard the oif when source address is specified despite the fact that a matching nexthop exists: # for i in {1..100}; do ip route get 2001:db8:10::${i} from 2001:db8:2::1 oif dummy2; done | grep -o dummy[0-9] | sort | uniq -c 53 dummy1 47 dummy2 This behavior differs from IPv4: # ip address add 192.0.2.1/32 dev lo # ip route add 198.51.100.0/24 nexthop via inet6 fe80::1 dev dummy1 nexthop via inet6 fe80::2 dev dummy2 # for i in {1..100}; do ip route get 198.51.100.${i} from 192.0.2.1 oif dummy2; done | grep -o dummy[0-9] | sort | uniq -c 100 dummy2 What happens is that fib6_table_lookup() returns a route with a matching nexthop device (assuming it exists): # perf record -e fib6:fib6_table_lookup -- bash -c "for i in {1..100}; do ip route get 2001:db8:10::${i} from 2001:db8:2::1 oif dummy2; done > /dev/null" # perf script | grep -o dummy[0-9] | sort | uniq -c 100 dummy2 But it is later overwritten during path selection in fib6_select_path() which instead chooses a nexthop according to the calculated hash. Solve this by telling fib6_select_path() to skip path selection if we have an oif match during output route lookup (iif being LOOPBACK_IFINDEX). Behavior after the change: # sysctl -wq net.ipv6.conf.all.forwarding=1 # ip route add 2001:db8:10::/64 nexthop via fe80::1 dev dummy1 nexthop via fe80::2 dev dummy2 # for i in {1..100}; do ip route get 2001:db8:10::${i} from 2001:db8:2::1 oif dummy2; done | grep -o dummy[0-9] | sort | uniq -c 100 dummy2 Note that enabling forwarding is only needed because we did not add neighbor entries for the gateway addresses. When forwarding is disabled and CONFIG_IPV6_ROUTER_PREF is not enabled in kernel config, the kernel will treat non-existing neighbor entries as errors and perform round-robin between the nexthops: # sysctl -wq net.ipv6.conf.all.forwarding=0 # for i in {1..100}; do ip route get 2001:db8:10::${i} from 2001:db8:2::1 oif dummy2; done | grep -o dummy[0-9] | sort | uniq -c 50 dummy1 50 dummy2 Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260611154605.992528-3-idosch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12ipv6: Select best matching nexthop object in fib6_table_lookup()Ido Schimmel
Currently, when using multipath routes without nexthop objects, fib6_table_lookup() selects the nexthop with the highest score. This means that when both a source address and an oif are specified, the nexthop that is chosen is the one that matches in terms of oif: # sysctl -wq net.ipv6.conf.all.forwarding=1 # ip address add 2001:db8:2::1/64 dev lo # ip route add 2001:db8:10::/64 nexthop via fe80::1 dev dummy1 nexthop via fe80::2 dev dummy2 # perf record -e fib6:fib6_table_lookup -- bash -c "for i in {1..100}; do ip route get 2001:db8:10::${i} from 2001:db8:2::1 oif dummy1; done > /dev/null" # perf script | grep -o dummy[0-9] | sort | uniq -c 100 dummy1 # perf record -e fib6:fib6_table_lookup -- bash -c "for i in {1..100}; do ip route get 2001:db8:10::${i} from 2001:db8:2::1 oif dummy2; done > /dev/null" # perf script | grep -o dummy[0-9] | sort | uniq -c 100 dummy2 When using nexthop objects, fib6_table_lookup() selects the first matching nexthop and not necessarily the one with the highest score: # ip nexthop add id 1 via fe80::1 dev dummy1 # ip nexthop add id 2 via fe80::2 dev dummy2 # ip nexthop add id 3 group 1/2 # ip route add 2001:db8:20::/64 nhid 3 # perf record -e fib6:fib6_table_lookup -- bash -c "for i in {1..100}; do ip route get 2001:db8:20::${i} from 2001:db8:2::1 oif dummy1; done > /dev/null" # perf script | grep -o dummy[0-9] | sort | uniq -c 100 dummy1 # perf record -e fib6:fib6_table_lookup -- bash -c "for i in {1..100}; do ip route get 2001:db8:20::${i} from 2001:db8:2::1 oif dummy2; done > /dev/null" # perf script | grep -o dummy[0-9] | sort | uniq -c 100 dummy1 This is not very significant right now because the nexthop is later overwritten during path selection in fib6_select_path(). However, the next patch is going to skip path selection when we have an oif match during output route lookup. As a preparation for this change, align the nexthop object behavior with the legacy one and make sure that fib6_table_lookup() always selects the best matching nexthop. Do that by always returning 0 from rt6_nh_find_match() in order not to terminate the loop in nexthop_for_each_fib6_nh() and storing in arg->nh the best matching nexthop so far. Behavior after the change: # perf record -e fib6:fib6_table_lookup -- bash -c "for i in {1..100}; do ip route get 2001:db8:20::${i} from 2001:db8:2::1 oif dummy1; done > /dev/null" # perf script | grep -o dummy[0-9] | sort | uniq -c 100 dummy1 # perf record -e fib6:fib6_table_lookup -- bash -c "for i in {1..100}; do ip route get 2001:db8:20::${i} from 2001:db8:2::1 oif dummy2; done > /dev/null" # perf script | grep -o dummy[0-9] | sort | uniq -c 100 dummy2 Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20260611154605.992528-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12netconsole: clear cached dev_name on resume-window cleanupBreno Leitao
When process_resume_target() catches a device that was unregistered while the target was off target_list, it calls do_netpoll_cleanup() to release the reference but leaves the cached np.dev_name in place. The other cleanup path, netconsole_process_cleanups_core(), already wipes dev_name for MAC-bound targets because the name was only a cache of the device that last carried the MAC and may no longer match. The pattern is the same in both spots, so fold it into a small helper netcons_release_dev() and route both call sites through it. This makes the resume-window cleanup consistent with the notifier-driven one so a later enable does not let netpoll_setup() pick a stale interface by name when the user bound the target by MAC. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Andre Carvalho <asantostc@gmail.com> Link: https://patch.msgid.link/20260610-netconsole_fix_more-v1-1-a18652c47cef@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: ethernet: mtk_wed: fix loading WO firmware for MT7986Zhi-Jun You
MT7986 requires a different mask for second WO firmware. Without this, WO would timeout after loading FW. The correct mask was removed when adding WED for MT7988. Add it back and add a WED version check to fix it. This can be reproduced with a MT7986 + MT7916 board. Fixes: e2f64db13aa1 ("net: ethernet: mtk_wed: introduce WED support for MT7988") Signed-off-by: Zhi-Jun You <hujy652@gmail.com> Link: https://patch.msgid.link/20260611150051.586-1-hujy652@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-07-09 03:20:51 +0000