summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-06-12net: watchdog: fix refcount tracking racesEric Dumazet
Blamed commit converted the untracked dev_hold()/dev_put() calls in the watchdog code to use the tracked dev_hold_track()/dev_put_track() (which were later renamed/interfaced to netdev_hold() and netdev_put()). By introducing dev->watchdog_dev_tracker to store the reference tracking information without adding synchronization between netdev_watchdog_up() and dev_watchdog(), it enabled the race condition where this pointer could be overwritten or freed concurrently, leading to the list corruption crash syzbot reported: list_del corruption, ffff888114a18c00->next is NULL kernel BUG at lib/list_debug.c:52 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 91 Comm: kworker/u8:5 Not tainted syzkaller #0 PREEMPT(lazy) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/09/2026 Workqueue: events_unbound linkwatch_event RIP: 0010:__list_del_entry_valid_or_report.cold+0x22/0x2a lib/list_debug.c:52 Call Trace: <TASK> __list_del_entry_valid include/linux/list.h:132 [inline] __list_del_entry include/linux/list.h:246 [inline] list_move_tail include/linux/list.h:341 [inline] ref_tracker_free+0x1a7/0x6c0 lib/ref_tracker.c:329 netdev_tracker_free include/linux/netdevice.h:4491 [inline] netdev_put include/linux/netdevice.h:4508 [inline] netdev_put include/linux/netdevice.h:4504 [inline] netdev_watchdog_down net/sched/sch_generic.c:600 [inline] dev_deactivate_many+0x28c/0xfe0 net/sched/sch_generic.c:1363 dev_deactivate+0x109/0x1d0 net/sched/sch_generic.c:1397 linkwatch_do_dev net/core/link_watch.c:184 [inline] linkwatch_do_dev+0xd3/0x120 net/core/link_watch.c:166 __linkwatch_run_queue+0x3a5/0x810 net/core/link_watch.c:240 linkwatch_event+0x8f/0xc0 net/core/link_watch.c:314 process_one_work+0xa0e/0x1980 kernel/workqueue.c:3314 process_scheduled_works kernel/workqueue.c:3397 [inline] worker_thread+0x5ef/0xe50 kernel/workqueue.c:3478 kthread+0x370/0x450 kernel/kthread.c:436 ret_from_fork+0x69a/0xc80 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 This patch has three coordinated parts: 1) Add dev->watchdog_lock and dev->watchdog_ref_held to serialize watchdog operations. 2) Remove netdev_watchdog_up() call from netif_carrier_on(): This ensures netdev_watchdog_up() is only called from process/BH context (via linkwatch workqueue dev_activate()), allowing us to use spin_lock_bh() for synchronization. 3) Synchronize watchdog up and watchdog timer: Protect netdev_watchdog_up() with tx_global_lock and watchdog_lock. Only allocate a new tracker in netdev_watchdog_up() if one is not already present. In dev_watchdog(), ensure we don't release the tracker if the timer was rescheduled either by dev_watchdog() itself or concurrently by netdev_watchdog_up(). Fixes: f12bf6f3f942 ("net: watchdog: add net device refcount tracker") Reported-by: syzbot+381d82bbf0253710b35d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a26b751.c25708ab.1b19ef.0013.GAE@google.com/T/#u Tested-by: syzbot+3479efbc2821cb2a79f2@syzkaller.appspotmail.com Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260611152737.2580480-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests: iou-zcrx: defer listen() until after zcrx setupDragos Tatulea
The server binds the queues for zero-copy after listen(). If the client does a connect() during this time it can fail with EHOSTUNREACH on a cold system. This was encountered with the mlx5 driver where binding the .ndo_queue_start() is a slow operation during which no packets can be exchanged. This change moves listen() after queue binding, when the test server is fully operational. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Link: https://patch.msgid.link/20260611160341.3697227-2-dtatulea@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge branch 'net-mana-fix-error-path-issues-in-queue-setup'Jakub Kicinski
Aditya Garg says: ==================== net: mana: fix error-path issues in queue setup Two error-path fixes in MANA queue setup, both surfaced during Sashiko AI review of a recently upstreamed patch series. Patch 1 initializes queue->id to INVALID_QUEUE_ID in mana_gd_create_mana_wq_cq() so that a CQ creation failure before the firmware id is assigned does not NULL gc->cq_table[0] and silently break whichever real CQ owns that slot. This mirrors the existing pattern in mana_gd_create_eq(). Patch 2 guards mana_destroy_txq()'s call to mana_destroy_wq_obj() with an INVALID_MANA_HANDLE check, mirroring mana_destroy_rxq(). Without it, TX setup failures lead to a firmware-rejected destroy of (u64)-1 and a spurious error in dmesg. ==================== Link: https://patch.msgid.link/20260608101345.2267320-1-gargaditya@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE checkAditya Garg
mana_create_txq() has several error paths (after mana_alloc_queues() or mana_create_wq_obj() failure) where tx_qp[i].tx_object stays as the INVALID_MANA_HANDLE sentinel set at allocation. mana_destroy_txq() then unconditionally calls mana_destroy_wq_obj() with (u64)-1, which firmware rejects and logs an error. Mirror the RX-side pattern in mana_destroy_rxq() and skip the destroy when the handle is still INVALID_MANA_HANDLE. Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com> Reviewed-by: Dipayaan Roy <dipayanroy@linux.microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Link: https://patch.msgid.link/20260608101345.2267320-3-gargaditya@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: mana: initialize gdma queue id to INVALID_QUEUE_IDAditya Garg
mana_gd_create_mana_wq_cq() leaves queue->id as 0 (from kzalloc_obj()) until mana_create_wq_obj() assigns the firmware-returned id. If creation fails before that, cleanup calls mana_gd_destroy_cq() with id 0, NULLing gc->cq_table[0] and silently breaking whichever real CQ owns that slot. Initialize queue->id to INVALID_QUEUE_ID right after allocation, matching mana_gd_create_eq(). The existing (id >= max_num_cqs) guard then short-circuits cleanly. Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com> Reviewed-by: Dipayaan Roy <dipayanroy@linux.microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Link: https://patch.msgid.link/20260608101345.2267320-2-gargaditya@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge branch 'net-mdio-realtek-rtl9300-add-rtl931x-support'Jakub Kicinski
Markus Stockhausen says: ==================== net: mdio: realtek-rtl9300: Add RTL931x support The Realtek Otto switch platform consists of four different series - RTL838x aka maple : 28 port 1G Switches - RTL839x aka cypress : 52 port 1G Switches - RTL930x aka longan : 28 port 1G/2.5G/10G Switches - RTL931x aka mango : 56 port 1G/2.5G/10G Switches This patch series adds support for the RTL931x devices. For this - Enhance device tree binding. - Implement final cleanups and enhancments for the driver. - Add RTL931x coding. Remark: Instead of this series it was planned to bring support for hardware polling configuration first. It turns out that more testing is needed - especially for the RTL83xx SoCs. Instead add the lineup of the RTL931x devices, that are known to have no obvious bus and polling issues (at least from testing and vendor SDK perspective). ==================== Link: https://patch.msgid.link/20260610194145.4153668-1-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: mdio: realtek-rtl9300: Add support for RTL931xMarkus Stockhausen
The MDIO driver has been prepared for multiple device support. Add all required bits for the RTL931x (aka mango) series. This is straightforward but some things are worth to be mentioned. - In contrast to RTL930x the I/O register has the input/output fields swapped. Upper 16 bits are for read/outputs, and the lower 16 bits are for write/inputs. - The supported "pages" are 8192 and thus the raw page is 8191 - The devices support up to 56 ports. Thus the MAX_PORTS definition is increased by this commit. - There are multiple global SMI controller registers with a different layout from RTL930x devices. Therefore a separate setup_controller() callback is added. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260610194145.4153668-6-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: mdio: realtek-rtl9300: Add registers for high port count modelsMarkus Stockhausen
The high port count models of the Realtek Otto switches have additional registers to instrument the MDIO controller. These are: - High port mask: A bitfield that extends the already existing low port mask to select ports starting from 32. - Broadcast: This takes the port number during reads on the RTL931x. - Extended page: Some additional page info. The SDK does not give much information about this. Basically some fixed value must be written into it during access. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260610194145.4153668-5-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: mdio: realtek-rtl9300: Make otto_emdio_read_cmd() genericMarkus Stockhausen
The otto_emdio_read_cmd() helper still uses RTL9300 specific properties. This cannot be made generic as the I/O register has different layouts for the different SoCs. E.g. - RTL930x: data in bits 31-16, data out bits 15-0 - RTL931x: data in bits 15-0, data out bits 31-16 Add a mask parameter to the function signature and fill it properly in the callers. As the masks will always have bits set from constant defines, there is no need for a consistency check. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260610194145.4153668-4-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: mdio: realtek-rtl9300: Add prefix to register field definesMarkus Stockhausen
The current Realtek Otto MDIO driver has some define leftovers without a SoC prefix. When adding new devices there will be an overlap for some of them. Sort this out as follows: - PHY_CTRL_CMD/PHY_CTRL_MMD_DEVAD/PHY_CTRL_MMD_REG are common for all series. Leave them as is but move them into a separate block. - Add RTL9300 prefix to all other defines and adapt the callers. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260610194145.4153668-3-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12dt-bindings: net: realtek,rtl9301-mdio: Add RTL931x seriesMarkus Stockhausen
The 10G Realtek Otto switches are divided into two series - Longan: RTL930x up to 28 ports - Mango : RTL931x up to 56 ports The Mango based devices have 3 different SoCs RTL9311, RTL9312 and RTL9313. The MDIO controller of these switches works like the existing RTL930x logic but has different characteristics and different registers. Add new compatibles in the device tree. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260610194145.4153668-2-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge tag 'pinctrl-v7.1-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: - Two fixes for the mcp23s08 driver. - Revert an earlier fix to the AMD pin controller that was all wrong. A proper fix is being developed. * tag 'pinctrl-v7.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: Revert "pinctrl-amd: enable IRQ for WACF2200 touchscreen on Lenovo Yoga 7 14AGP11" pinctrl: mcp23s08: Read spi-present-mask as u8 not u32 pinctrl: mcp23s08: Initialize mcp->dev and mcp->addr before regmap init
2026-06-12Merge branch 'avoid-mistaken-parent-class-deactivation-during-peek'Jakub Kicinski
Victor Nogueira says: ==================== Avoid mistaken parent class deactivation during peek Several qdiscs (fq_codel, codel and dualpi2) may drop packets while peeking at their queue. When that happens they call qdisc_tree_reduce_backlog() to notify the parent of the backlog/qlen change. The problem is that they do so *before* reincrementing the qlen that peek had temporarily decremented. If the qlen momentarily drops to zero while peek still has an skb to return, qdisc_tree_reduce_backlog() ends up invoking the parent's qlen_notify() callback even though the child is not actually empty. The parent then deactivates the class, while the child still holds a packet. For parents such as QFQ this desync corrupts the active class list and leads to wild memory accesses and NULL pointer dereferences (see the per-patch splats). For HFSC it might lead to stalls [1]. Fix all three qdiscs the same way: only call qdisc_tree_reduce_backlog() once the qlen has been restored, so the parent never observes a transient empty child during peek. Patch 1 fixes this for fq_codel, patch 2 for codel, patch 3 for dualpi2 and patch 4 adds test cases for these 3 setups. Note: Patch 1 is one of two fixes for the stall reported in [1]; the companion fix is "net/sched: sch_hfsc: Don't make class passive twice", sent separately. Note2: A possible cleaner fix is to create a new helper function for peek that only calls qdisc_tree_reduce_backlog after reincrementing the qlen. This would be called from the 3 vulnerable qdiscs, however we thought this might make it harder for backporting so, if people agree, we can submit this cleaner version to net-next after this one is merged. [1] https://lore.kernel.org/netdev/CAN2cbVe79oj0O9==m4+4x3v+O+qzRagA=2=wkrp9i9=CqYvyZA@mail.gmail.com/ ==================== Link: https://patch.msgid.link/20260610192855.3121513-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests/tc-testing: Verify child qdisc will not mistakenly deactivate QFQ ↵Victor Nogueira
parent Create 3 test cases: - Verify fq_codel won't mistakenly deactivate QFQ parent class during peek - Verify codel won't mistakenly deactivate QFQ parent class during peek - Verify dualpi2 won't mistakenly deactivate QFQ parent class during peek Verify that these 3 qdiscs (fq_codel, codel, dualpi2) will not call qdisc_tree_reduce_backlog with an incorrect qlen (0) during peek and mistakenly deactivate a parent class. Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Victor Nogueira <victor@mojatatu.com> Link: https://patch.msgid.link/20260610192855.3121513-5-victor@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net/sched: sch_dualpi2: Do not call qdisc_tree_reduce_backlog during peek ↵Victor Nogueira
before restoring qlen Whenever dualpi2 drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though dualpi2 still has 1 packet on the queue and, thus, mistakenly deactivates the parent's class which leads to a null-ptr-deref: [ 101.427314][ T599] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000009: 0000 [#1] SMP KASAN NOPTI [ 101.427755][ T599] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 101.428048][ T599] CPU: 2 UID: 0 PID: 599 Comm: ping Not tainted 7.1.0-rc5-00284-gbce53c430ed7 #102 PREEMPT(full) [ 101.428400][ T599] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 101.428608][ T599] RIP: 0010:qfq_dequeue (net/sched/sch_qfq.c:1150) sch_qfq [ 101.428821][ T599] Code: 00 fc ff df 80 3c 02 00 0f 85 46 0c 00 00 4c 8d 73 48 48 89 9d b8 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 2d 0c 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b All code [ 101.429348][ T599] RSP: 0018:ffff8881110df4f0 EFLAGS: 00010216 [ 101.429541][ T599] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: dffffc0000000000 [ 101.429763][ T599] RDX: 0000000000000009 RSI: 00000024c0000000 RDI: ffff88811436c2b0 [ 101.429985][ T599] RBP: ffff88811436c000 R08: ffff88811436c280 R09: 1ffff11021277523 [ 101.430206][ T599] R10: 1ffff11021277526 R11: 1ffff11021277527 R12: 00000024c0000000 [ 101.430423][ T599] R13: ffff88811436c2b8 R14: 0000000000000048 R15: 0000000020000000 [ 101.430642][ T599] FS: 00007f61813e1c40(0000) GS:ffff8881691ef000(0000) knlGS:0000000000000000 [ 101.430913][ T599] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 101.431100][ T599] CR2: 00005651650850a8 CR3: 000000010ca0b000 CR4: 0000000000750ef0 [ 101.431320][ T599] PKRU: 55555554 [ 101.431433][ T599] Call Trace: [ 101.431544][ T599] <TASK> [ 101.431628][ T599] __qdisc_run (net/sched/sch_generic.c:322 net/sched/sch_generic.c:427 net/sched/sch_generic.c:445) [ 101.431792][ T599] ? dev_qdisc_enqueue (./include/trace/events/qdisc.h:49 (discriminator 22) net/core/dev.c:4176 (discriminator 22)) [ 101.431941][ T599] __dev_queue_xmit (./include/net/pkt_sched.h:120 ./include/net/pkt_sched.h:117 net/core/dev.c:4292 net/core/dev.c:4831) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored. Fixes: 8f9516daedd6 ("sched: Add enqueue/dequeue of dualpi2 qdisc") Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Victor Nogueira <victor@mojatatu.com> Link: https://patch.msgid.link/20260610192855.3121513-4-victor@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek ↵Victor Nogueira
before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored. Fixes: 342debc12183 ("codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog()") Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Victor Nogueira <victor@mojatatu.com> Link: https://patch.msgid.link/20260610192855.3121513-3-victor@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during peek ↵Victor Nogueira
before restoring qlen Whenever fq_codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though fq_codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a recent report [1] and a wild memory access in qfq: [ 29.371146][ T360] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 29.371666][ T360] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 29.371987][ T360] CPU: 6 UID: 0 PID: 360 Comm: tc Not tainted 7.1.0-rc5-00285-gc530e5b2dbc6-dirty #82 PREEMPT(full) [ 29.372384][ T360] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 29.372620][ T360] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 29.373544][ T360] RSP: 0018:ffff888102417370 EFLAGS: 00010216 [ 29.373800][ T360] RAX: 0000000000000000 RBX: ffff88811224d568 RCX: dffffc0000000000 [ 29.374079][ T360] RDX: 1ffff11021fe1543 RSI: ffff88810ff0aa00 RDI: dffffc0000000000 [ 29.374368][ T360] RBP: ffff88811224c280 R08: dead000000000122 R09: 1bd5a00000000024 [ 29.374649][ T360] R10: fffffbfff7940329 R11: fffffbfff7940329 R12: 0000000000000000 [ 29.374926][ T360] R13: dead000000000100 R14: ffff88811224d580 R15: ffff88811224d578 [ 29.375207][ T360] FS: 00007f5b794e5780(0000) GS:ffff88815d1e9000(0000) knlGS:0000000000000000 [ 29.375545][ T360] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 29.375823][ T360] CR2: 000055ffb091f000 CR3: 000000010a305000 CR4: 0000000000750ef0 [ 29.376103][ T360] PKRU: 55555554 [ 29.376258][ T360] Call Trace: [ 29.376401][ T360] <TASK> ... [ 29.376885][ T360] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 29.377074][ T360] qdisc_reset (net/sched/sch_generic.c:1057) [ 29.377414][ T360] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 29.377600][ T360] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 29.378593][ T360] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored. [1] http://lore.kernel.org/netdev/CAN2cbVe79oj0O9==m4+4x3v+O+qzRagA=2=wkrp9i9=CqYvyZA@mail.gmail.com/ Fixes: 342debc12183 ("codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog()") Reported-by: Anirudh Gupta <anirudhrudr@gmail.com> Closes: https://lore.kernel.org/netdev/CAN2cbVe79oj0O9==m4+4x3v+O+qzRagA=2=wkrp9i9=CqYvyZA@mail.gmail.com/ Tested-by: Anirudh Gupta <anirudhrudr@gmail.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Victor Nogueira <victor@mojatatu.com> Link: https://patch.msgid.link/20260610192855.3121513-2-victor@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge branch 'ipv6-mcast-annotate-data-races-in-proc-net-igmp6'Jakub Kicinski
Yuyang Huang says: ==================== ipv6: mcast: annotate data races in /proc/net/igmp6 /proc/net/igmp6 walks IPv6 multicast memberships under RCU without holding idev->mc_lock, taking a lockless snapshot of two fields that writers update under the lock: mca_flags and mca_work.timer.expires. Patch 1 adds WRITE_ONCE() to all mca_flags update sites and READ_ONCE() to the procfs reader. Patch 2 does the same for the timer.expires read in the procfs path. ==================== Link: https://patch.msgid.link/20260609081113.7613-1-sigefriedhyy@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12ipv6: mcast: annotate igmp6 timer expiry raceYuyang Huang
/proc/net/igmp6 walks IPv6 multicast memberships under RCU and reads mca_work.timer.expires to print the remaining multicast timer. The delayed-work timer can be updated concurrently. Annotate the intentional lockless procfs snapshot with READ_ONCE(). Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260609081113.7613-3-sigefriedhyy@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12ipv6: mcast: annotate data-races around mca_flagsYuyang Huang
/proc/net/igmp6 walks IPv6 multicast memberships under RCU and prints mca_flags without holding idev->mc_lock. The multicast paths update the field while holding idev->mc_lock. Annotate this intentional lockless snapshot with READ_ONCE() and the matching writers with WRITE_ONCE(). Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260609081113.7613-2-sigefriedhyy@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge branch 'rxrpc-miscellaneous-fixes'Jakub Kicinski
David Howells says: ==================== rxrpc: Miscellaneous fixes Here are some miscellaneous AF_RXRPC fixes: (1) Make sure rxrpc_verify_data() allocates a buffer, even if the DATA packet being looked at is zero length to avoid potential NULL-pointer exceptions. (2) Don't move an OOB message (e.g. an RxGK CHALLENGE) off the receive queue onto the pending queue in recvmsg() if MSG_PEEK is specified. (3) Fix a potential UAF in rxgk_issue_challenge() in which a tracepoint refers to memory just freed by a different pointer. (4) Fix afs net namespace teardown to cancel the incoming call preallocation charger before we disable listening (which will delete the preallocation queue). (5) Fix rxrpc_kernel_charge_accept() to use the socket mutex to defend against listen(0)/shutdown simultaneously deleting the preallocation queue. ==================== Link: https://patch.msgid.link/20260609140911.838677-1-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12rxrpc: serialize kernel accept preallocation with socket teardownLi Daming
rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog. Fixes: 00e907127e6f ("rxrpc: Preallocate peers, conns and calls for incoming service requests") Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Signed-off-by: Li Daming <d4n.for.sec@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260609140911.838677-6-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12afs: Fix netns teardown to cancel the preallocation chargerDavid Howells
Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review). Fixes: 00e907127e6f ("rxrpc: Preallocate peers, conns and calls for incoming service requests") Reported-by: Simon Horman <horms@kernel.org> Signed-off-by: David Howells <dhowells@redhat.com> cc: Li Daming <d4n.for.sec@gmail.com> cc: Ren Wei <n05ec@lzu.edu.cn> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260609140911.838677-5-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12rxrpc: Fix UAF in rxgk_issue_challenge()David Howells
Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed. Fixes: 9d1d2b59341f ("rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)") Reported-by: Marc Dionne <marc.dionne@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260609140911.838677-4-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12rxrpc: Don't move a peeked OOB message onto the pending queueHyunwoo Kim
rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so only unlink it from recvmsg_oobq and then move it onto pending_oobq or free it when the message is actually consumed. Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE") Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260609140911.838677-3-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12rxrpc: rxrpc_verify_data ensure rx_dec_buffer allocJeffrey Altman
rxrpc_recvmsg_data() calls rxrpc_verify_data() whenever the rxrpc_call.rx_dec_buffer is unallocated and assumes that upon successful return that rx_dec_buffer must be allocated. However, rxrpc_verify_data() does not request an allocation if the rxrpc_skb_priv.len is zero. In addition, failure to allocate rx_dec_buffer will result in a call to skb_copy_bits() with a NULL destination which can trigger a NULL pointer dereference. To prevent these issues rxrpc_verify_data() is modified to always attempt to allocate the rxrpc_call.rx_dec_buffer if it is NULL. This issue was identified with assistance of a private sashiko instance. Fixes: d2bc90cf6c75cb ("rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg") Reported-by: Simon Horman <simon.horman@redhat.com> Signed-off-by: Jeffrey Altman <jaltman@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: Jiayuan Chen <jiayuan.chen@linux.dev> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260609140911.838677-2-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge branch 'net-remove-tls_toe'Jakub Kicinski
Sabrina Dubroca says: ==================== net: remove tls_toe This series removes the tls_toe feature, its single user (chtls), and cleans up the EXPORT_SYMBOL()s that no other module requires. Driver changes only compile-tested. ==================== Link: https://patch.msgid.link/cover.1781165969.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: remove some unused EXPORT_SYMBOL()sSabrina Dubroca
chtls was using a lot of symbols that no other module requires. Remove those EXPORT_SYMBOL()s. Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/d124db74f6f0838b652f0ee4b4530964f3cf8d49.1781165969.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12tls: remove tls_toe and the related driverSabrina Dubroca
The tls_toe feature and its single user (chelsio chtls) have been unmaintained for multiple years. It also hooks into the core of the TCP implementation, and bypasses most of the networking stack. Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/1f30e73275c07bf879f547589872d0916025a52e.1781165969.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12ethtool: tsconfig: always take rtnl_lockJakub Kicinski
mlx5 throws ASSERT_RTNL() warnings on timestamp config, because it tries to update features. mlx5e_hwtstamp_set() calls netdev_update_features(). I missed this while grepping the drivers because tsconfig goes through ndo_hwtstamp_set/get, not ethtool ops, even tho the new uAPI is in ethtool Netlink. We could add a dedicated opt out bit for mlx5, but NDOs were not supposed to be part of the ethtool locking conversion in the first place. The mlx5 features update is related to the "compressed CQE" format which lacks timestamp, apparently. See commit c0194e2d0ef0 ("net/mlx5e: Disable rxhash when CQE compress is enabled"). Fixes: f9a3e05114b8 ("net: ethtool: optionally skip rtnl_lock on Netlink path for SET ops") Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20260611200355.2020663-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12ip_tunnel: annotate data-races around t->err_count and t->err_timeEric Dumazet
ip_tunnel_xmit() runs locklessly (dev->lltx == true). ipgre_err() and ipip_err() also run locklessly. We need to add READ_ONCE() and WRITE_ONCE() annotations around t->err_count and t->err_time. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260611165247.2710257-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12virtio_net: do not allow tunnel csum offload for non GSO packetsPaolo Abeni
Fiona reports broken connectivity for virtio net setup using UDP tunnel inside the guest and NIC with not UDP tunnel TSO support in the host. Currently the virtio_net driver exposes csum offload for UDP-tunneled, TCP non GSO packets. Such packet reach the host as CSUM_PARTIAL ones with the 'encapsulation' flag cleared, as the virtio specification do not support this specific kind of offload. HW NICs with UDP tunnel TSO support - and those drivers directly accessing skb->csum_start/csum_offset - are still capable of computing the needed csum correctly, but otherwise the packets reach the wire with bad csum on both the inner and outer transport header. Address the issue explicitly disabling csum offload for UDP tunneled, non GSO packets via the ndo_features_check op. Fixes: 56a06bd40fab ("virtio_net: enable gso over UDP tunnel support.") Reported-by: Fiona Ebner <f.ebner@proxmox.com> Closes: https://bugzilla.proxmox.com/show_bug.cgi?id=7627 Tested-by: Fiona Ebner <f.ebner@proxmox.com> Tested-by: Gabriel Goller <g.goller@proxmox.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Gabriel Goller <g.goller@proxmox.com> Tested-by: Gabriel Goller <g.goller@proxmox.com> Link: https://patch.msgid.link/6c3b6c47fb05c100f384630dc48f3975cf37b67a.1781195144.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: atm: reject out-of-range traffic classes in QoS validationZhengchuan Liang
Reject ATM traffic classes above ATM_ANYCLASS in check_tp(). SO_ATMQOS stores the supplied QoS after check_qos() succeeds, so accepting larger values leaves invalid traffic_class values in vcc->qos. That bad state later reaches pvc_info(), which indexes class_name[] with vcc->qos.{rx,tp}.traffic_class. Values above ATM_ANYCLASS cause an out-of-bounds read when /proc/net/atm/pvc is read. Tighten the existing QoS validation so invalid traffic_class values are rejected at the point where user supplied QoS is accepted. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/58f02c6f73d9818fd5d2022e1116759fdde6116b.1780965530.git.zcliangcn@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: hsr: simplify fill_last_seq_nrs()Yury Norov
The function checks the HSR_PT_SLAVE_A and HSR_PT_SLAVE_B bitmaps for emptiness right before calling find_last_bit(). This pass may be avoided, because if the bitmap is empty, the find_last_bit() returns >= HSR_SEQ_BLOCK_SIZE Signed-off-by: Yury Norov <ynorov@nvidia.com> Reviewed-by: Felix Maurer <fmaurer@redhat.com> Link: https://patch.msgid.link/20260609171545.1051322-1-ynorov@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12tcp: clear sock_ops cb flags before force-closing a child socketSechang Lim
A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: <IRQ> tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 </IRQ> The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too. Suggested-by: Jiayuan Chen <jiayuan.chen@linux.dev> Fixes: d44874910a26 ("bpf: Add BPF_SOCK_OPS_STATE_CB") Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260611092923.1895982-1-rhkrqnwk98@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: ethernet: sis900: correct CONFIG_VLAN_8021Q macro name in commentEthan Nelson-Moore
A comment in drivers/net/ethernet/sis/sis900.h incorrectly refers to CONFIG_VLAN_802_1Q instead of CONFIG_VLAN_8021Q. Correct it. Discovered while searching for CONFIG_* symbols referenced in code but not defined in any Kconfig file. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260609175656.20574-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12docs: net: fix minor issues with XDP metadata docsJakub Kicinski
Minor updates to the XDP metadata documentation: - s/union/struct/ for xsk_tx_metadata - document nested request and completion metadata fields - point capability queries at the xsk-features attribute - fix grammar in the XDP RX metadata guide - typos Acked-by: Stanislav Fomichev <sdf@fomichev.me> Acked-by: Jesper Dangaard Brouer <hawk@kernel.org> Link: https://patch.msgid.link/20260609201224.1191391-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12bnxt: fix head underflow on XDP head-growJoe Damato
The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free. The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with this commit applied causes the test to run successfully to completion. The other rx_skb_func implementations don't have this issue. Fixes: f6974b4c2d8e ("bnxt_en: Fix page pool logic for page size >= 64K") Signed-off-by: Joe Damato <joe@dama.to> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20260609204458.2237787-2-joe@dama.to Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12net: stmmac: xgmac2: disable RBUE in default RX interrupt maskNazim Amirul
Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA runs out of RX descriptors it fires RBUE continuously until software refills the ring. However, RBUE is redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handle_rx - the same outcome as RIE. On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio - confirming the severity of the storm. RBUE does not provide OOM recovery. If page_pool is exhausted, stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix. Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions. Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal RX handling intact. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260609121703.9736-1-muhammad.nazim.amirul.nazle.asmade@altera.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge tag 'drm-fixes-2026-06-13' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Looks like it's settled down a bit more thankfully. Small changes across the board, amdgpu/xe leading with some colorop changes in the core/amd. Otherwise some misc driver fixes. colorop: - make lut interpolation mutable - track colorop updates correctly amdgpu: - UserQ fix - Userptr fix - MCCS freesync fix - track colorop changes correctly amdkfd: - Fix an event information leak - Events bounds check fix - Trap cleanup fix i915: - Check supported link rates DPCD read - Fix phys BO pread/pwrite with offset xe: - fix oops in suspend/shutdown without display - RAS fixes - Use HW_ERR prefix in log - include all registered queues in TLB invalidation - Fix refcount leak in xe_range_tree in error paths - fix job timeout recovery for unstarted jobs and kernel queues amdxdna: - fix possible leak of mm_struct ivpu: - fix integer truncation vc4: - fix leak in krealloc() error handling virtio: - fix dma_fence ref-count leak" * tag 'drm-fixes-2026-06-13' of https://gitlab.freedesktop.org/drm/kernel: (24 commits) accel/amdxdna: Fix mm_struct reference leak in aie2_populate_range() drm/xe: fix job timeout recovery for unstarted jobs and kernel queues drm/xe: fix refcount leak in xe_range_fence_insert() drm/xe: include all registered queues in TLB invalidation drm/xe/hw_error: Use HW_ERR prefix in log drm/xe/drm_ras: Add per node cleanup action drm/xe/drm_ras: Make counter allocation drm managed drm/xe/display: fix oops in suspend/shutdown without display drm/amd/display: use plane color_mgmt_changed to track colorop changes drm/atomic: track individual colorop updates drm/colorop: make lut(1/3)d_interpolation props correctly behave as mutable drm/colorop: Remove read-only comments from interpolation fields drm/i915/gem: Fix phys BO pread/pwrite with offset drm/vc4: fix krealloc() memory leak drm/virtio: Fix driver removal with disabled KMS drm/i915/edp: Check supported link rates DPCD read accel/ivpu: Fix signed integer truncation in IPC receive drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() drm/amd/display: Consult MCCS FreeSync cap only if requested & supported drm/amdkfd: Unwind debug trap enable on copy_to_user failure ...
2026-06-12handshake: Require admin permission for DONE commandChuck Lever
ACCEPT and DONE are the two downcalls of the handshake genl family, both intended for use by the trusted handshake agent (tlshd). ACCEPT already requires GENL_ADMIN_PERM; DONE has no privilege check at all. The fd-lookup in handshake_nl_done_doit() only confirms that some pending handshake request exists for the supplied sockfd; it does not authenticate the sender. An unprivileged process that guesses or observes a valid sockfd can therefore submit a DONE with HANDSHAKE_A_DONE_STATUS == 0, leaving the kernel consumer to proceed as if the handshake succeeded. A non-zero status on a forged DONE tears down a legitimate in-flight handshake before tlshd can report its real result. Fixes: 3b3009ea8abb ("net/handshake: Create a NETLINK service for handling handshake requests") Reviewed-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Hannes Reinecke <hare@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Link: https://patch.msgid.link/20260609141831.90694-1-cel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12Merge branch 'selftests-xsk-simplify-umem-setup'Jakub Kicinski
Tushar Vyavahare says: ==================== selftests/xsk: simplify UMEM setup This series simplifies UMEM handling in selftests/xsk. It centralizes UMEM property setup through helpers, moves UMEM ownership from ifobject to socket-owned state, and normalizes umem_size/mmap_size usage across the touched paths. ==================== Link: https://patch.msgid.link/20260608130938.958793-1-tushar.vyavahare@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests/xsk: Introduce mmap_size in umem structTushar Vyavahare
UMEM teardown currently recomputes the munmap() length from frame geometry, shared-UMEM adjustment, and hugepage rounding. This duplicates setup-time logic in cleanup and relies on re-deriving the mapping size instead of using the size originally established for the mapping. Store the final mapping length in xsk_umem_info as mmap_size when the UMEM mapping is created, and use that value during teardown. Also join the RX worker thread before cleanup in the single-thread path. This establishes synchronization before reading umem->mmap_size in teardown and avoids a potential visibility race. This removes duplicated size arithmetic in cleanup and makes munmap() use the canonical mapping size recorded at setup time. Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by: Tushar Vyavahare <tushar.vyavahare@intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Link: https://patch.msgid.link/20260608130938.958793-5-tushar.vyavahare@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests/xsk: Use umem_size() helper consistentlyTushar Vyavahare
Replace remaining open-coded `umem->num_frames * umem->frame_size` calculations in test_xsk.c with the existing `umem_size()` helper. This keeps UMEM size computation centralized, avoids duplicated arithmetic, and improves readability with no intended behavior change. Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by: Tushar Vyavahare <tushar.vyavahare@intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Link: https://patch.msgid.link/20260608130938.958793-4-tushar.vyavahare@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests/xsk: Move UMEM state from ifobject to xsk_socket_infoTushar Vyavahare
Move UMEM ownership from ifobject to xsk_socket_info and access it through xsk->umem. Allocate one shared umem_real in ifobject_create() and let all sockets reference it through xsk->umem, while keeping ownership in xsk_arr[0]. Keep the existing goto-based error path in ifobject_create() and free the allocation once in ifobject_delete(). Reset the existing umem_real in __test_spec_init() with memset() instead of reallocating it. Preserve shared-UMEM behavior by copying RX UMEM state into a TX-local UMEM state in thread_common_ops_tx() and reset base_addr/next_buffer before TX socket configuration. Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by: Tushar Vyavahare <tushar.vyavahare@intel.com> Link: https://patch.msgid.link/20260608130938.958793-3-tushar.vyavahare@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-12selftests/xsk: Introduce helpers for setting UMEM propertiesTushar Vyavahare
UMEM properties are set via open-coded field assignments in multiple test paths, which makes updates noisy and error-prone. Introduce two helpers to set UMEM properties through a single interface. This keeps setup logic consistent across tests and makes future refactoring simpler. No functional behavior change is intended. Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by: Tushar Vyavahare <tushar.vyavahare@intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Link: https://patch.msgid.link/20260608130938.958793-2-tushar.vyavahare@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-13pinctrl: Match DT helper typesRob Herring (Arm)
The affected pinctrl drivers either check for the presence of a standard property or read a property documented with an 8-bit cell encoding. Using boolean or u32 helpers for those cases disagrees with the binding. Use a presence helper for "gpio-ranges" and read "microchip,spi-present-mask" with the u8 helper documented by the binding. Assisted-by: Codex:gpt-5-5 Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-06-12dt-bindings: embedded-controller: Add Qualcomm reference device EC descriptionMaya Matuszczyk
Add description for the EC firmware running on Hamoa/Purwa and Glymur reference devices. Signed-off-by: Maya Matuszczyk <maccraft123mc@gmail.com> Co-developed-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com> Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com> Link: https://patch.msgid.link/20260511-add-driver-for-ec-v9-1-e5437c39b7f8@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-06-12dt-bindings: pwm: add IPQ6018 bindingDevi Priya
DT binding for the PWM block in Qualcomm IPQ6018 SoC. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Co-developed-by: Baruch Siach <baruch.siach@siklu.com> Signed-off-by: Baruch Siach <baruch.siach@siklu.com> Signed-off-by: Devi Priya <quic_devipriy@quicinc.com> Signed-off-by: George Moussalem <george.moussalem@outlook.com> Link: https://patch.msgid.link/20260406-ipq-pwm-v21-1-6ed1e868e4c2@outlook.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-06-12selftests: tc: act_pedit: require matching IPv4 L4 protocolVictor Nogueira
Add a tdc test that checks the act_pedit extended L4 header mode does not edit a packet whose IPv4 protocol does not match the selected transport header. The test installs an ingress pedit rule that sets the UDP destination port, then injects a TCP packet with dport 2222. The UDP and TCP destination ports sit at the same L4 offset, so a buggy kernel rewrites the TCP dport. A second flower filter matches TCP dport 2222 and drops the packet through an indexed gact action; the test then verifies via JSON that this action saw exactly one packet, i.e. the dport was left untouched and still matched 2222. Signed-off-by: Victor Nogueira <victor@mojatatu.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-07-09 08:40:10 +0000