summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-08-22net_sched: sch_fq: fix pacing delay underflow with pacing offloadEric Dumazet
When pacing offload is enabled (q->offload_horizon > 0), FQ can dequeue packets early (now < f->time_next_packet). In this case, the drift calculation (now - f->time_next_packet) underflows to a large unsigned value. min(len/2, now - f->time_next_packet) then evaluates to len/2, incorrectly halving the pacing delay for the next packet. Fix this by only applying drift compensation if now > f->time_next_packet. This bug was triggered when flow_max_rate was set on the qdisc or for non EDT packets (packets with a zero skb->tstamp). Fixes: f26080d47007 ("net_sched: sch_fq: add the ability to offload pacing") Reported-by: Willem de Bruijn <willemb@google.com> Closes: https://lore.kernel.org/netdev/CANn89iK6O7ujR9zCJzd04MNLQoDi3mA+HWsR-hgQWYzLS3gZfw@mail.gmail.com/ Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260820120706.1995449-1-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22net: page_pool: Remove zone/policy GFP flags when allocating XArray entriesRong Zhang
Net drivers request GFP flags according to both the current context and the device constraints, but the XArray entry itself is by no mean used by the device. Passing though device constraints to XArray allocation is a bug and will be warned and fixed up by slab, e.g.: Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0x82820 (GFP_ATOMIC|__GFP_NOWARN|__GFP_NOMEMALLOC). Fix your code! CPU: 2 UID: 0 PID: 1071629 Comm: kworker/u80:1 Not tainted 7.2.0-rc7+ #1 PREEMPT(lazy) Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN27WW 10/20/2025 Workqueue: mt76 mt792x_pm_wake_work [mt792x_lib] Call Trace: <TASK> dump_stack_lvl+0x6e/0x90 kmalloc_fix_flags+0x4d/0x6a refill_objects+0x10a/0x330 __pcs_replace_empty_main+0x292/0x5c0 kmem_cache_alloc_lru_noprof+0x4c2/0x680 ? __xas_nomem+0x3a/0x120 __xas_nomem+0x3a/0x120 __xa_alloc+0xd4/0x190 page_pool_dma_map+0xef/0x400 __page_pool_alloc_netmems_slow+0xed/0x480 ? lock_release+0x280/0x490 page_pool_alloc_frag_netmem+0xe0/0x3a0 page_pool_alloc_frag+0xe/0x20 mt76_dma_rx_fill_buf+0x1f6/0x580 [mt76] mt76_dma_rx_reset+0x1cf/0x230 [mt76] mt792x_wpdma_reset+0x183/0x1b0 [mt792x_lib] mt792x_wpdma_reinit_cond+0x5e/0xa0 [mt792x_lib] mt792xe_mcu_drv_pmctrl+0x28/0x60 [mt792x_lib] mt792x_mcu_drv_pmctrl+0x3e/0x90 [mt792x_lib] mt792x_pm_wake_work+0x2d/0x1d0 [mt792x_lib] ? process_one_work+0x20e/0x600 process_one_work+0x230/0x600 ? process_one_work+0x256/0x600 worker_thread+0x1ec/0x3c0 ? rescuer_thread+0x610/0x610 kthread+0xf2/0x130 ? kthread_affine_node+0x140/0x140 ret_from_fork+0x2a5/0x380 ? kthread_affine_node+0x140/0x140 ret_from_fork_asm+0x11/0x20 </TASK> Currently mt76 and stmmac may allocate page pool pages with GFP_DMA32. Fix it by removing zone/policy GFP flags when allocating XArray entries. This is inspired by commit 96d578088085 ("iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous()"). Fixes: ee62ce7a1d90 ("page_pool: Track DMA-mapped pages and unmap them when destroying the pool") Signed-off-by: Rong Zhang <i@rong.moe> Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com> Link: https://patch.msgid.link/20260821-page-pool-xa-drop-dma32-v1-1-6eab295c3478@rong.moe Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22Merge branch ↵Jakub Kicinski
'net-smc-fix-out-of-bounds-and-use-after-free-in-smc-rv2-llc-processing' Yehyeong Lee says: ==================== net/smc: fix out-of-bounds and use-after-free in SMC-Rv2 LLC processing Patch 1 fixes a use-after-free of the LLC queue entry in smc_llc_srv_add_link(), patch 2 bounds the peer's rkey counts, and patch 3 carries the tail of an oversized v2 message in the queue entry so that both readers are bounded by what arrived. All three are tagged for stable: a tree that takes 1 and 2 without 3 still deletes rkeys read from whatever an earlier message left in the shared receive buffer. ==================== Link: https://patch.msgid.link/20260819023306.644849-1-yhlee@isslab.korea.ac.kr Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22net/smc: carry oversized SMC-Rv2 LLC messages in the queue entryYehyeong Lee
smc_llc_rmt_delete_rkey() and smc_llc_save_add_link_rkeys() read the part of a v2 message that does not fit into the 44-byte union smc_llc_msg, and both bound themselves by the size of the buffer it landed in, not by what arrived. On a link with a shared v2 receive buffer a 44-byte DELETE_RKEY_V2 declaring 255 rkeys reaches rkey[9..254] in whatever an earlier message left in lgr->wr_rx_buf_v2, and passes each of them to smc_rtoken_delete(). One of those 255 matched a registered rtoken and deleted it. An ADD_LINK on such a link installs up to 255 rtokens from the same bytes. Copy the tail into the queue entry, so its length is the length of the message that arrived, and declare the rkeys that fit inline as a member of the union instead of reaching them through a cast. The same DELETE_RKEY_V2 now processes the 9 rkeys it carries. The copy is limited to the longest tail the two functions can read, so the peer does not pick the size of the entry. The bound the previous patch placed on links without a shared v2 receive buffer is no longer needed. Fixes: 27ef6a9981fe ("net/smc: support SMC-R V2 for rdma devices with max_recv_sge equals to 1") Cc: stable@vger.kernel.org Suggested-by: D. Wythe <alibuda@linux.alibaba.com> Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com> Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr> Link: https://patch.msgid.link/20260819023306.644849-4-yhlee@isslab.korea.ac.kr Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22net/smc: bound the peer rkey counts in SMC-Rv2 LLC messagesYehyeong Lee
On a link whose device has max_recv_sge == 1 there is no shared v2 receive buffer, and smc_llc_save_add_link_rkeys() takes the v2 extension from 44 bytes past the start of the queue entry's inline message: ext = (struct smc_llc_msg_add_link_v2_ext *)(llc_msg + SMC_WR_TX_SIZE); The entry is a 72-byte allocation and the extension starts at offset 68, so ext->num_rkeys at offset 94 is already past it. This happens on every SMC-Rv2 link addition, whatever the peer sends: [ 2.490065] BUG: KASAN: slab-out-of-bounds in smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490431] Read of size 2 at addr ffff8880056406de by task smctest/106 [ 2.490709] [ 2.490792] CPU: 0 UID: 0 PID: 106 Comm: smctest Not tainted 7.2.0-rc5-p1-g77a5d9d9c99f #32 PREEMPT(lazy) [ 2.490795] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 2.490798] Call Trace: [ 2.490803] <TASK> [ 2.490805] dump_stack_lvl+0x53/0x70 [ 2.490810] print_report+0xd0/0x630 [ 2.490828] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 2.490832] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490834] kasan_report+0xce/0x100 [ 2.490836] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490837] smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.490839] ? smcr_buf_map_lgr+0x1bf/0x2b0 [ 2.490844] smc_llc_cli_add_link+0xca7/0x1e80 [ 2.490848] ? smc_llc_wait+0x355/0x810 [ 2.490850] ? __pfx_smc_llc_wait+0x10/0x10 [ 2.490851] ? __pfx_smc_llc_cli_add_link+0x10/0x10 [ 2.490853] ? __pfx_autoremove_wake_function+0x10/0x10 [ 2.490863] __smc_connect+0x3f5c/0x4980 [ 2.490873] ? __pfx_kernel_connect+0x10/0x10 [ 2.490888] ? __pfx___smc_connect+0x10/0x10 [ 2.490891] ? release_sock+0x148/0x1d0 [ 2.490894] smc_connect+0x42c/0x580 [ 2.490896] __sys_connect+0xfc/0x130 [ 2.490898] ? __pfx___sys_connect+0x10/0x10 [ 2.490900] ? handle_mm_fault+0x1a1/0x430 [ 2.490908] __x64_sys_connect+0x6d/0xb0 [ 2.490909] ? fpregs_assert_state_consistent+0x56/0xe0 [ 2.490917] do_syscall_64+0xf9/0x540 [ 2.490921] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 2.490924] RIP: 0033:0x421bb4 [ 2.490927] Code: ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d ad 34 09 00 00 74 13 b8 2a 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 10 89 55 [ 2.490929] RSP: 002b:00007ffd473b01a8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a [ 2.490935] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000421bb4 [ 2.490936] RDX: 0000000000000010 RSI: 00007ffd473b01d0 RDI: 0000000000000003 [ 2.490937] RBP: 0000000000003930 R08: 0000000000000004 R09: 0000000000000000 [ 2.490938] R10: 00007ffd473b0f98 R11: 0000000000000202 R12: 0000000000000006 [ 2.490939] R13: 00007ffd473b0f87 R14: 0000000000000003 R15: 00007ffd473b0f90 [ 2.490940] </TASK> [ 2.490941] [ 2.499545] Allocated by task 44: [ 2.499693] kasan_save_stack+0x33/0x60 [ 2.499860] kasan_save_track+0x14/0x30 [ 2.500026] __kasan_kmalloc+0x8f/0xa0 [ 2.500190] __kmalloc_cache_noprof+0x158/0x370 [ 2.500393] smc_llc_enqueue+0x72/0x560 [ 2.500559] smc_wr_rx_tasklet_fn+0x474/0xa80 [ 2.500747] tasklet_action_common+0x20f/0x8a0 [ 2.500945] handle_softirqs+0x18e/0x590 [ 2.501115] do_softirq+0x3b/0x60 [ 2.501266] __local_bh_enable_ip+0x61/0x70 [ 2.501446] __alloc_skb+0x732/0x890 [ 2.501604] rxe_init_packet+0x16b/0x4f0 [ 2.501783] prepare_ack_packet+0xb8/0x830 [ 2.501962] rxe_receiver+0x495/0x96e0 [ 2.502125] do_work+0x144/0x470 [ 2.502269] process_one_work+0x633/0x1030 [ 2.502450] worker_thread+0x45b/0xd10 [ 2.502617] kthread+0x2c6/0x3b0 [ 2.502762] ret_from_fork+0x36e/0x5a0 [ 2.502925] ret_from_fork_asm+0x1a/0x30 [ 2.503103] [ 2.503177] The buggy address belongs to the object at ffff888005640680 [ 2.503177] which belongs to the cache kmalloc-96 of size 96 [ 2.503692] The buggy address is located 22 bytes to the right of [ 2.503692] allocated 72-byte region [ffff888005640680, ffff8880056406c8) [ 2.504227] [ 2.504300] The buggy address belongs to the physical page: [ 2.504535] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5640 [ 2.504865] flags: 0x100000000000000(node=0|zone=1) [ 2.505076] page_type: f5(slab) [ 2.505221] raw: 0100000000000000 ffff888001041280 dead000000000122 0000000000000000 [ 2.505544] raw: 0000000000000000 0000000000200020 00000000f5000000 0000000000000000 [ 2.505867] page dumped because: kasan: bad access detected [ 2.506102] [ 2.506176] Memory state around the buggy address: [ 2.506380] ffff888005640580: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [ 2.506683] ffff888005640600: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [ 2.506987] >ffff888005640680: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [ 2.507291] ^ [ 2.507548] ffff888005640700: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [ 2.507850] ffff888005640780: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc Whatever that read finds then bounds the ext->rt[] loop, so a peer that declares 255 rkeys reads much further. smc_llc_rmt_delete_rkey() has the same shape for llcv2->rkey[]. Bound both loops by the buffer they read from, and skip the extension altogether when there is no shared v2 receive buffer. The extension does arrive on the link, but smc_llc_enqueue() copies only sizeof(union smc_llc_msg) into the queue entry, so what that code read past the 44 inline bytes was heap and not peer data. Fixes: 27ef6a9981fe ("net/smc: support SMC-R V2 for rdma devices with max_recv_sge equals to 1") Cc: stable@vger.kernel.org Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com> Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr> Link: https://patch.msgid.link/20260819023306.644849-3-yhlee@isslab.korea.ac.kr Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link()Yehyeong Lee
smc_llc_srv_add_link() keeps add_llc pointing into the queue entry: add_llc = &qentry->msg.add_link; smc_llc.c:1482 ... smc_llc_save_add_link_info(link_new, add_llc); smc_llc.c:1494 smc_llc_flow_qentry_del(&lgr->llc_flow_lcl); smc_llc.c:1495 ... u8 *llc_msg = smc_link_shared_v2_rxbuf(link) ? (u8 *)lgr->wr_rx_buf_v2 : (u8 *)add_llc; smc_llc.c:1504 smc_llc_save_add_link_rkeys(link, link_new, llc_msg); smc_llc.c:1506 smc_llc_flow_qentry_del() kfree()s the entry, so on a link without a shared v2 receive buffer the pointer handed to smc_llc_save_add_link_rkeys() is already freed. Before the Fixes: commit that branch always used lgr->wr_rx_buf_v2 and add_llc was not used after the free. Reproduced on an unpatched tree over rxe, with KASAN, kasan_multi_shot and a link forced to max_recv_sge == 1: the entry is freed and read by the same call, and the freeing frame is smc_llc_srv_add_link() itself. [ 2.523161] BUG: KASAN: slab-use-after-free in smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523499] Read of size 2 at addr ffff8880052194de by task kworker/0:1/11 [ 2.523789] [ 2.523862] CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 7.2.0-rc5-p0-g2c9dd296545d #35 PREEMPT(lazy) [ 2.523865] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 2.523866] Workqueue: smc_hs_wq smc_listen_work [ 2.523869] Call Trace: [ 2.523870] <TASK> [ 2.523871] dump_stack_lvl+0x53/0x70 [ 2.523872] print_report+0xd0/0x630 [ 2.523874] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 2.523876] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523878] kasan_report+0xce/0x100 [ 2.523879] ? smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523881] smc_llc_save_add_link_rkeys+0x333/0x350 [ 2.523883] ? smcr_buf_reg_lgr+0x2a4/0x660 [ 2.523885] smc_llc_srv_add_link+0xaa2/0x1e50 [ 2.523888] ? _printk+0xba/0xf0 [ 2.523897] ? __pfx_smc_llc_srv_add_link+0x10/0x10 [ 2.523899] ? down_write+0xb0/0x130 [ 2.523903] ? __pfx_down_write+0x10/0x10 [ 2.523905] smc_listen_work+0x489e/0x4d00 [ 2.523907] ? kmem_cache_free+0x1c6/0x3a0 [ 2.523911] ? __pfx_smc_listen_work+0x10/0x10 [ 2.523913] ? release_sock+0x148/0x1d0 [ 2.523915] ? smc_tcp_listen_work+0xb4f/0xfc0 [ 2.523917] ? _raw_spin_lock_irq+0x80/0xe0 [ 2.523918] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 2.523920] process_one_work+0x633/0x1030 [ 2.523922] ? assign_work+0x11d/0x370 [ 2.523924] worker_thread+0x45b/0xd10 [ 2.523926] ? __pfx_worker_thread+0x10/0x10 [ 2.523928] ? __pfx_worker_thread+0x10/0x10 [ 2.523929] kthread+0x2c6/0x3b0 [ 2.523931] ? recalc_sigpending+0x15c/0x1e0 [ 2.523934] ? __pfx_kthread+0x10/0x10 [ 2.523935] ret_from_fork+0x36e/0x5a0 [ 2.523937] ? __pfx_ret_from_fork+0x10/0x10 [ 2.523938] ? __switch_to+0x572/0xdd0 [ 2.523943] ? __pfx_kthread+0x10/0x10 [ 2.523944] ret_from_fork_asm+0x1a/0x30 [ 2.523947] </TASK> [ 2.523948] [ 2.531253] Allocated by task 48: [ 2.531399] kasan_save_stack+0x33/0x60 [ 2.531570] kasan_save_track+0x14/0x30 [ 2.531737] __kasan_kmalloc+0x8f/0xa0 [ 2.531905] __kmalloc_cache_noprof+0x158/0x370 [ 2.532100] smc_llc_enqueue+0x72/0x560 [ 2.532268] smc_wr_rx_tasklet_fn+0x474/0xa80 [ 2.532491] tasklet_action_common+0x20f/0x8a0 [ 2.532714] handle_softirqs+0x18e/0x590 [ 2.532886] do_softirq+0x3b/0x60 [ 2.533036] __local_bh_enable_ip+0x61/0x70 [ 2.533221] __alloc_skb+0x732/0x890 [ 2.533384] rxe_init_packet+0x16b/0x4f0 [ 2.533567] prepare_ack_packet+0xb8/0x830 [ 2.533760] rxe_receiver+0x495/0x96e0 [ 2.533933] do_work+0x144/0x470 [ 2.534078] process_one_work+0x633/0x1030 [ 2.534257] worker_thread+0x45b/0xd10 [ 2.534424] kthread+0x2c6/0x3b0 [ 2.534569] ret_from_fork+0x36e/0x5a0 [ 2.534737] ret_from_fork_asm+0x1a/0x30 [ 2.534907] [ 2.534980] Freed by task 11: [ 2.535112] kasan_save_stack+0x33/0x60 [ 2.535279] kasan_save_track+0x14/0x30 [ 2.535444] kasan_save_free_info+0x3b/0x60 [ 2.535625] __kasan_slab_free+0x43/0x70 [ 2.535798] kfree+0x121/0x380 [ 2.535935] smc_llc_srv_add_link+0x9a8/0x1e50 [ 2.536128] smc_listen_work+0x489e/0x4d00 [ 2.536305] process_one_work+0x633/0x1030 [ 2.536482] worker_thread+0x45b/0xd10 [ 2.536652] kthread+0x2c6/0x3b0 [ 2.536794] ret_from_fork+0x36e/0x5a0 [ 2.536958] ret_from_fork_asm+0x1a/0x30 [ 2.537133] [ 2.537205] The buggy address belongs to the object at ffff888005219480 [ 2.537205] which belongs to the cache kmalloc-96 of size 96 [ 2.537719] The buggy address is located 94 bytes inside of [ 2.537719] freed 96-byte region [ffff888005219480, ffff8880052194e0) [ 2.538216] [ 2.538289] The buggy address belongs to the physical page: [ 2.538524] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5219 [ 2.538857] flags: 0x100000000000000(node=0|zone=1) [ 2.539066] page_type: f5(slab) [ 2.539210] raw: 0100000000000000 ffff888001041280 dead000000000122 0000000000000000 [ 2.539534] raw: 0000000000000000 0000000000200020 00000000f5000000 0000000000000000 [ 2.539863] page dumped because: kasan: bad access detected [ 2.540098] [ 2.540170] Memory state around the buggy address: [ 2.540379] ffff888005219380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 2.540684] ffff888005219400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 2.540988] >ffff888005219480: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 2.541291] ^ [ 2.541548] ffff888005219500: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [ 2.541857] ffff888005219580: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc The offset is past the 72-byte queue entry because the out-of-bounds read fixed by the next patch is on the same line; what this patch removes is the free at smc_llc_srv_add_link+0x9a8 happening before the read at +0xaa2. Detach the entry instead of freeing it there, and free it at the single exit label. The reject path has to detach as well, otherwise it would be freed twice. This changes only the lifetime of the entry. The same read still runs past its end until the next two patches bound it, so a backport wants all three. Fixes: 27ef6a9981fe ("net/smc: support SMC-R V2 for rdma devices with max_recv_sge equals to 1") Cc: stable@vger.kernel.org Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com> Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260819023306.644849-2-yhlee@isslab.korea.ac.kr Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22net: libwx: fix concurrent bitmap overwrite in PTP setupJiawen Wu
In wx_ptp_set_timestamp_mode(), the driver copies the global `wx->flags` bitmap to a local variable, modifies the PTP-related bits, and then writes the entire bitmap back using memcpy(). This Read-Copy-Update pattern is unsafe and introduces a critical race condition. Other asynchronous contexts (such as Tx timeout routines or GPIO IRQ handlers) update individual bits in `wx->flags` concurrently using atomic bitops like set_bit() or clear_bit(). The memcpy() write-back can silently overwrite and drop these concurrent changes, potentially causing the driver to miss critical module reset or PCIe recovery requests. Fix this by removing the local bitmap copy. Instead, evaluate the intended PTP flag states locally and apply them directly to `wx->flags` using atomic set_bit() and clear_bit() operations only after the hardware is successfully configured. Fixes: 06e75161b9d4 ("net: wangxun: Add support for PTP clock") Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/6C7EC12D69217315+20260818074721.45536-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22qede: Fix NULL pointer dereference in TPA fragment processingVaibhav Nagare
Under memory pressure, the qede driver encounters NULL pointer dereferences when processing TPA continuation fragments. Commit 8a8633978b84 ("qede: Add build_skb() support.") accidentally dropped the assignment of tpa_info->buffer.data in qede_tpa_start(). When memory pressure causes an SKB allocation failure in qede_tpa_start(), the driver sets tpa_start_fail = true and attempts to recycle the physical page later in qede_tpa_end() via qede_reuse_page(). However, because buffer.data was left uninitialized (NULL), qede_reuse_page() pushes a "ghost" BD (valid DMA mapping but NULL data pointer) back into the active Rx ring. The next time the hardware uses this ring slot, it passes a NULL page to qede_fill_frag_skb(), causing a kernel panic. Example crash from production system: BUG: unable to handle kernel NULL pointer dereference at 0x8 RIP: qede_fill_frag_skb+0x96/0x430 [qede] Call Trace: qede_rx_int+0xb06/0x1de0 qede_poll+0x2f4/0x6c0 __napi_poll+0x2d/0x130 Fix the root cause by restoring the tpa_info->buffer.data assignment in qede_tpa_start(), ensuring valid pages are correctly tracked and recycled. Additionally, update the stale comment for struct qede_agg_info::buffer to reflect its current usage. Fixes: 8a8633978b84 ("qede: Add build_skb() support.") Cc: stable@vger.kernel.org Signed-off-by: Vaibhav Nagare <vnagare@redhat.com> Link: https://patch.msgid.link/20260818073309.2266072-1-vnagare@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22net: txgbe: fix MISC interrupt unmasking in non-MSI-X mode and device shutdownJiawen Wu
In txgbe_misc_irq_thread_fn(), the driver unmasks the miscellaneous interrupt at the end of the handler using TXGBE_INTR_MISC(wx) (which resolves to BIT(wx->num_q_vectors)). While this is correct for MSI-X mode, it is incorrect for legacy INTx or single MSI modes. Due to hardware behavior, the WX_PX_MISC_IVAR register is completely ignored by the hardware when MSI-X is disabled. In non-MSI-X mode, the hardware forcibly merges all interrupt causes (both Queue and MISC) into a single bit: BIT(0) of the interrupt register. Unconditionally unmasking TXGBE_INTR_MISC(wx) (e.g., BIT(1)) in non-MSI-X mode means the actual MISC interrupt bit (BIT(0)) is not unmasked promptly at the end of the MISC thread. Instead, it remains masked until NAPI completes its polling and unmasks the shared BIT(0). This delays the assertion of subsequent MISC interrupts, preventing timely handling of events like link state changes. Fix this by explicitly checking `pdev->msix_enabled` and falling back to BIT(0) as the interrupt mask for the MISC cause when MSI-X is disabled. Additionally, unconditionally unmasking the interrupt at the end of the thread introduces a race condition during device teardown. Guarding the wx_intr_enable() call with a check for the WX_STATE_DOWN bit, to prevent re-arming the interrupt during device shutdown. Fixes: e37546ad1f9b ("net: wangxun: revert the adjustment of the IRQ vector sequence") Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/56A53978B83EEDE9+20260818023026.6631-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22Merge branch 'net-sparx5-misc-fixes-for-sparx5-and-lan969x'Jakub Kicinski
Daniel Machon says: ==================== net: sparx5: misc fixes for sparx5 and lan969x This series fixes various issues in the sparx5 driver, which also serves lan969x. Details are in the individual commit descriptions. ==================== Link: https://patch.msgid.link/20260817-misc-fixes-sparx5-lan969x-v3-0-c7c7fef723a8@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22net: sparx5: fix sleep in atomic context in MAC table accessDaniel Machon
sparx5_set_rx_mode() runs with netif_addr_lock_bh held and iterates dev->mc via __dev_mc_sync(), which per address calls sparx5_mc_sync() / sparx5_mc_unsync() -> sparx5_mact_learn() / sparx5_mact_forget(). These take sparx5->lock, a mutex, and then poll the MAC access command register with readx_poll_timeout(). A mutex may block, which is not allowed from atomic context. Convert the driver to the new .ndo_set_rx_mode_async callback introduced in commit 3554b4345d85 ("net: introduce ndo_set_rx_mode_async and netdev_rx_mode_work"). The async callback is invoked from process context, so the mutex and sleeping completion poll can remain. Observed with CONFIG_PROVE_LOCKING, CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_MUTEXES and CONFIG_DEBUG_ATOMIC_SLEEP enabled: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 217, name: ip preempt_count: 201, expected: 0 Call trace: __might_resched+0x144/0x248 __might_sleep+0x48/0x7c __mutex_lock+0x74/0x850 mutex_lock_nested+0x24/0x30 sparx5_mact_learn+0x78/0x100 sparx5_mc_sync+0x40/0x54 __hw_addr_sync_dev+0xc4/0x170 sparx5_set_rx_mode+0x4c/0x58 __dev_set_rx_mode+0x64/0xa4 __dev_open+0x1ec/0x26c Fixes: d6fce5141929 ("net: sparx5: add switching support") Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20260817-misc-fixes-sparx5-lan969x-v3-2-c7c7fef723a8@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22net: microchip: vcap: use port number instead of netdev name for debugfsDaniel Machon
sparx5_vcap_init() runs before sparx5_register_netdevs() in probe, and its debugfs setup calls vcap_port_debugfs() for every port using netdev_name(ndev) as the debugfs file name. At that point the netdevs have only been allocated, not registered, so dev->name still holds the "eth%d" template and netdev_name() returns "(unnamed net_device)". Every port tries to create the same file under vcaps/, producing a flood of warnings at boot: debugfs: '(unnamed net_device)' already exists in 'vcaps' debugfs: '(unnamed net_device)' already exists in 'vcaps' ... Add vcap_port_debugfs_portno(), a variant of vcap_port_debugfs() that takes the port's stable hardware port number and uses "p%u" as the debugfs file name instead of netdev_name(ndev). This makes the file name independent of registration order; the file still stores and later dereferences the netdev itself, same as before. sparx5 already reports the same "p%d" string via ndo_get_phys_port_name(), so the debugfs name now matches that. Only sparx5 (and lan969x, which shares this code) is switched to the new function. lan966x keeps calling vcap_port_debugfs() unchanged, so this fix does not rename any of its existing debugfs files. Fixes: b8909aad5b8d ("net: sparx5: move netdev and notifier block registration to probe") Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20260817-misc-fixes-sparx5-lan969x-v3-1-c7c7fef723a8@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22gtp: serialize PDP context updatesQing Ming
PDP contexts can be deleted through GTP_CMD_DELPDP or while the GTP network device is being unregistered. The latter is serialized by RTNL, but the generic-netlink delete path only holds RCU. Running both paths concurrently can therefore make both paths delete the same PDP context. The issue was found through static analysis and reproduced on a KASAN-enabled kernel by a simple two-thread program racing GTP_CMD_DELPDP against RTM_DELLINK: Oops: general protection fault, probably for non-canonical address KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] RIP: gtp_genl_del_pdp+0x1c1/0x420 [gtp] RBP: dead000000000122 The second deletion dereferenced the poisoned hlist pprev pointer. Serialize gtp_pdp_add(), gtp_genl_del_pdp(), and gtp_dellink() with a shared mutex. Keep the mutex held until the final use of a PDP context in the NEWPDP path, and keep the RCU read-side section around the complete PDP context use in the DELPDP path. Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Cc: stable@vger.kernel.org Signed-off-by: Qing Ming <a0yami@mailbox.org> Link: https://patch.msgid.link/20260818150000.7670-1-a0yami@mailbox.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22xdp: fix zero-copy frame layoutWeiming Shi
xdp_convert_zc_to_xdp_frame() clones an XSK packet into an order-0 page and advertises PAGE_SIZE as its frame size. It allows the copied frame to occupy the page tail needed by skb_shared_info and records zero headroom even when metadata separates the frame header from packet data. An AF_XDP zero-copy packet redirected through cpumap can therefore make the skb overlap skb_shared_info or place it beyond the allocated page. Limit the copied layout to SKB_WITH_OVERHEAD(PAGE_SIZE) and include the metadata length in frame headroom. Redirect callers already handle a NULL conversion result. BUG: KASAN: slab-out-of-bounds in skb_gro_receive Write of size 4 at addr ffff88800cf37004 by task cpumap/1/map:1/146 Call Trace: skb_gro_receive (net/core/gro.c:174) udp_gro_receive (net/ipv4/udp_offload.c:812) inet_gro_receive (net/ipv4/af_inet.c:1539) dev_gro_receive (net/core/gro.c:515) gro_receive_skb (net/core/gro.c:633) cpu_map_kthread_run (kernel/bpf/cpumap.c:395) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) Kernel panic - not syncing: KASAN: panic_on_warn set ... Fixes: b0d1beeff2a9 ("xdp: implement convert_to_xdp_frame for MEM_TYPE_ZERO_COPY") Cc: stable@vger.kernel.org Reported-by: Xiang Mei <xmei5@asu.edu> Signed-off-by: Weiming Shi <bestswngs@gmail.com> Link: https://patch.msgid.link/20260818154516.793517-1-bestswngs@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22Merge branch 'net-ntb_netdev-fix-rx-statistics-accounting'Jakub Kicinski
Koichiro Den says: ==================== net: ntb_netdev: Fix RX statistics accounting This series addresses Jakub's comment on ntb_netdev RX statistics accounting: https://lore.kernel.org/r/20260818092938.4121c220@kernel.org/ It fixes the double counting and also the related packet/byte accounting on RX refill failure. ==================== Link: https://patch.msgid.link/20260819172539.1450821-1-den@valinux.co.jp Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22net: ntb_netdev: Count packets dropped on RX refill failureKoichiro Den
When replacement skb allocation fails, ntb_netdev drops a packet that was received successfully and requeues the original buffer. The drop is counted, but rx_packets and rx_bytes are not. Count every good packet before allocating its replacement. Fixes: d2121faf133a ("NTB: ntb_netdev: Preserve RX queue depth on allocation failure") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den <den@valinux.co.jp> Link: https://patch.msgid.link/20260819172539.1450821-3-den@valinux.co.jp Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22net: ntb_netdev: Avoid double-accounting netif_rx() dropsKoichiro Den
netif_rx() already accounts packets it drops in the core rx_dropped counter. ntb_netdev counts them again as both errors and drops. Leave netif_rx() drops to the core. Count the packet and bytes unconditionally since it was received successfully by the driver. Fixes: 548c237c0a99 ("net: Add support for NTB virtual ethernet device") Cc: stable@vger.kernel.org Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Koichiro Den <den@valinux.co.jp> Link: https://patch.msgid.link/20260819172539.1450821-2-den@valinux.co.jp Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22tcp: clamp route advmss to TCP_MIN_MSSYong Wang
tcp_select_initial_window() assumes that callers never pass an MSS smaller than 1, but route-derived advmss values can violate that assumption. A too-small explicit RTAX_ADVMSS is one way to get there, but it is not the only one. The same divide-by-zero can also be reached through the "default advmss" path when RTAX_ADVMSS is left at 0 and the effective advmss is later driven down by route MTU and min_adv_mss. Introduce a tcp_dst_advmss() helper that clamps route advmss to TCP_MIN_MSS before TCP consumes it, and use it in the TCP paths that derive advmss from dst metrics. This keeps the effective MSS from dropping to zero before tcp_select_initial_window() rounds the receive window. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Vega <vega@nebusec.ai> Signed-off-by: Yong Wang <edragain@163.com> Signed-off-by: Ren Wei <weir@nebusec.ai> Link: https://patch.msgid.link/251eaf8277fa7c66364c9815c5da01662d269181.1787074852.git.edragain@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22ipip: fix skb leak in collect_md mode when metadata_dst allocation failsAnton Danilov
In collect_md mode ipip_tunnel_rcv() returns 0 without freeing the skb when ip_tun_rx_dst() fails to allocate the metadata_dst. ipip_rcv() and mplsip_rcv() are registered as xfrm_tunnel handlers, so tunnel4_rcv() and tunnelmpls4_rcv() read the zero return as "the packet has been consumed" and do not free it either. The skb is leaked. The other tunnel drivers all dispose of the packet at this point: ip6_tunnel.c jumps to its drop label, ip_gre.c and ip6_gre.c return PACKET_REJECT, which makes gre_rcv() free the skb. Only ipip returns 0. Jump to the existing drop label instead. It frees the skb and still returns 0, so the packet keeps being reported as consumed, which is what we want here: the outer header has already been pulled, and neither the remaining handlers nor an ICMP unreachable have any use for it. Triggering this needs an ipip or mplsip tunnel in collect_md mode and an atomic allocation failure, which is why it has gone unnoticed. Fixes: cfc7381b3002 ("ip_tunnel: add collect_md mode to IPIP tunnel") Cc: stable@vger.kernel.org Signed-off-by: Anton Danilov <littlesmilingcloud@gmail.com> Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de> Link: https://patch.msgid.link/20260819104338.432631-2-littlesmilingcloud@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22net/sched: account classifier filter allocations to memcgJamal Hadi Salim
Allocations in the tc classifier *_change() paths (filter objects, per-CPU counters, and per-filter aux data) use plain GFP_KERNEL without __GFP_ACCOUNT, allowing unprivileged users to pin kernel memory outside memcg charging. The shared tcf_exts_init_ex() action array allocation in cls_api.c was also uncharged; this patch closes it along with the per-classifier filter-object/percpu/aux allocations that remain unaccounted. Add GFP_KERNEL_ACCOUNT to: - the shared tcf_exts_init_ex() action array (cls_api.c), common to every filter of every classifier (32 pointers, 256 bytes); - the filter-object, per-CPU-counter, and per-filter aux allocations in cls_basic, cls_bpf, cls_cgroup, cls_flow, cls_flower, cls_fw, cls_matchall, cls_route and cls_u32; - the u32_init_knode() replace-path knode allocation (cls_u32.c), which allocates the same struct tc_u_knode + sel.keys on every replace of an existing knode and was missed by the create-path-only conversion. Also fix the cls_basic error path: basic_change() inserts fnew into the IDR before allocating the per-CPU counter. If alloc_percpu() fails the errout path kfree'd fnew without idr_remove, leaving a dangling pointer in the IDR. With GFP_KERNEL_ACCOUNT the percpu alloc becomes failable on demand (memcg at memory.max), making the dead path attacker-reachable and burning the handle permanently. Add the idr_remove on the percpu failure path, matching the basic_set_parms failure-path pattern. Note: vega@nebusec.ai provided a poc for basic_cls, but it was easy to extend to the other classifiers. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_CLS_* (the classifier being used), CONFIG_NET_CLS_ACT, CONFIG_MEMCG, CONFIG_USER_NS, CONFIG_NET_NS. - Unprivileged user in a fresh user+network namespace (unshare -Urn), or root with CAP_NET_ADMIN. - Create a large number of tc filters (e.g. tc filter add dev lo ingress ... <classifier> ...) while watching a memcg-limited cgroup: system slab grows far faster than memory.current, pinning kernel memory outside memcg charging. Fixes: 0da974f4f303 ("[NET]: Conversions from kmalloc+memset to k(z|c)alloc.") Reported-by: vega@nebusec.ai Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260819143733.57538-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22Merge tag 'batadv-net-pullrequest-20260821' of https://git.open-mesh.org/batadvJakub Kicinski
Simon Wunderlich says: ==================== Here are a few batman-adv bugfixes: - fix stale receive device on merged fragments, by Zhiling Zou the others are written by Sven Eckelmann: - bla: fix potential CRC corruption issues (2 patches) - dat: avoid unaligned fault in IP extraction - dat: atomically update mac addresses - mcast: fix TX priority extraction for BATADV_FORW_MCAST - mcast: fix skb sharing and linearization (2 patches) - bla: fix freeing of claims on meshif deletion * tag 'batadv-net-pullrequest-20260821' of https://git.open-mesh.org/batadv: batman-adv: bla: fix freeing of claims on meshif deletion batman-adv: mcast: linearize skbuff for packet generation batman-adv: mcast: ensure unshared skb for multicast packets batman-adv: fix TX priority extraction for BATADV_FORW_MCAST batman-adv: dat: atomically update mac addresses batman-adv: dat: avoid unaligned fault in IP extraction batman-adv: bla: prevent CRC corruptions after claim flush batman-adv: bla: avoid CRC corruption due to parallel claim add batman-adv: fix stale receive device on merged fragments ==================== Link: https://patch.msgid.link/20260821094813.201800-1-sw@simonwunderlich.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22ptp: netc: fix period truncation and potential divide-by-zero in PEROUTWei Fang
The max_period bound in net_timer_enable_perout() was computed as: max_period = (u64)NETC_TMR_DEFAULT_FIPER + integral_period; which exceeds U32_MAX when integral_period > 0 (e.g. 0x100000002 for the default 333333333 Hz clock). A period_ns that passes this check but exceeds U32_MAX is then silently truncated when stored into the u32 struct netc_pp::period field. A truncated value of zero can reach netc_timer_set_perout_alarm(), where the local u32 period variable would also be 0, causing a divide-by-zero in roundup_u64(delta, period) whenever the stime < min_time branch is taken (which always happens for a start time of {0, 0}). Additionally, netc_timer_enable_periodic_pulse() and netc_timer_enable_fiper() both compute: fiper = pp->period - integral_period; A zero pp->period results in an unsigned wraparound to 0xFFFFFFFD, mis-programming the FIPER hardware register. Fix all three issues by capping max_period at NETC_TMR_DEFAULT_FIPER (0xFFFFFFFF). This ensures that any period_ns passing the range check fits in a u32 without truncation, so the stored value is always valid and non-zero. The accepted range is reduced by integral_period ns (typically only a few nanoseconds), which is negligible in practice. Fixes: 671e266835b8 ("ptp: netc: add periodic pulse output support") Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://patch.msgid.link/20260821032449.1235065-1-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22bnxt_en: Gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API checkThomas Walsh
In bnxt_request_irq(), pcie_enable_tph() is called unconditionally to enable PCIe TPH when setting up interrupts. If the NIC hardware or firmware capabilities do not support queue ops, attempting to enable TPH during bnxt_request_irq() is unnecessary. As a result a flood of "RX queue restart failed: err=-95" messages is seen upon boot. Older NICs (pre-Thor / BCM57414) do not support TPH or queue management. TPH requires queue management to restart the queue. NICs that support queue management (with updated FW) all support TPH. Gate the call to pcie_enable_tph() and setting of bp->tph_mode behind BNXT_SUPPORTS_QUEUE_API(bp) to ensure TPH is only initialized on devices capable of supporting queue ops. This prevents a guaranteed -EOPNOTSUPP error from occurring due to NULL operations. Fixes: c214410c47d6 ("bnxt_en: Add TPH support in BNXT driver") Suggested-by: Michal Schmidt <mschmidt@redhat.com> Signed-off-by: Thomas Walsh <thwalsh@redhat.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://patch.msgid.link/20260820220544.1240879-1-thwalsh@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22bnxt_en: Fix call to hardware monitoring event handlerGuenter Roeck
The first parameter of hwmon_notify_event() is supposed to be the hardware monitoring device. The bnxt driver calls it with the platform device as first parameter instead. This API break results in undefined behavior and may result in a crash. Pass the hardware monitoring device as parameter instead to fix the problem. Fixes: a19b4801457b0 ("bnxt_en: Event handler for Thermal event") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260821044512.663941-1-linux@roeck-us.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-22sched_ext: Fix spurious aborts in scx_bpf_dsq_move() on ownership change racesTejun Heo
scx_dsq_move() verifies that the task belongs to the calling scheduler before taking any locks and aborts the scheduler on mismatch. The task can lose the sched association at any point: It can run and fully exit, which clears the association, or get rehomed to a different sub-sched. Both are benign races, but the early ownership check escalates them into scheduler aborts. Move the ownership check below the cursor-lost check. Every ownership change dequeues the task first, so a task that is still on the iterated DSQ under the lock while owned elsewhere indicates a genuine violation and should abort. Also fix two stale comments still referencing sched_ext_free(), which has been renamed to sched_ext_dead(). Fixes: bb4d9fd55158 ("sched_ext: scx_dsq_move() should validate the task belongs to the right scheduler") Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-22Merge tag 'caps-pr-20260820' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux Pull capabilities update from Serge Hallyn: "Just one trivial patch which corrects two comments to avoid kernel-doc warnings" * tag 'caps-pr-20260820' of git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux: capability: remove non-kernel-doc comments
2026-08-22Merge tag 'exfat-for-7.3-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat Pull exfat updates from Namjae Jeon: "A set of exfat fixes covering shared writable mappings, entry error handling, allocation cleanup, FITRIM bounds, and locking: - Fix valid_size extension over shared writable mappings by lazily zeroing page-cache gaps and ensuring racing stores cannot be overwritten or extend beyond valid_size - Clean up partially written directory entries on add-entry failure and safely free new directory clusters - Free a newly allocated directory cluster when zeroing it fails - Write the destination entry before removing the source entry during rename, preserving the source if the destination write fails - Keep FITRIM within the requested range, even when the free-space search wraps around the allocation bitmap - Fix truncated FS_IOC_GETFSLABEL results by passing the destination buffer size in bytes to the UTF-16-to-NLS conversion - Fix overflow in the cluster-to-dentry calculation, which could cause readdir to stop early on large volumes - Replace the per-inode truncate_lock with inode_lock, using shared locking in bmap to serialize against concurrent truncation - Update the exfat mailing list address in MAINTAINERS" * tag 'exfat-for-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat: exfat: replace truncate_lock with inode_lock exfat: keep FITRIM within the requested range exfat: fix truncated volume labels returned by FS_IOC_GETFSLABEL exfat: fix overflow in cluster-to-dentry conversion exfat: clean up new entry on add entry failure exfat: free new directory cluster if zeroing fails exfat: write moved entry before removing source MAINTAINERS: update mailing list address for exfat exfat: fix valid_size extension over a shared writable mapping
2026-08-22Merge tag 'perf-tools-for-v7.3-2026-08-21' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools Pull perf tools updates from Namhyung Kim: "perf c2c: - Add 'function view' in perf c2c report TUI (switched by pressing 'TAB' in the cacheline view) to organize samples around functions rather than cachelines in 3-level hierarchy: Level 1: Read-side function (sorted by estimated Cycles %) Level 2: Contending writer functions (sorted by Store count) Level 3: Shared cacheline addresses Users can navigate the entries and fold/unfold using 'e' key. An example output would look like below: Shared Data Functions Table (19 entries, sorted on Cycles %) Cycles Store % count Function / Contending function / Cacheline ---------------------------------------------------------------------- + 35.67% 876 + [k] cpupri_set + 24.31% 424 + [k] pull_rt_task - 16.53% 555 - [k] dequeue_pushable_task 145 - [k] pull_rt_task 145 0xff2d0082809da080 139 - [k] enqueue_pushable_task 70 0xff2d00a2071f9640 69 0xff2d0082809da000 python module support: - Extend "perf" python module so that it can be fully functional. The goal is to run scripts directly, not by 'perf script' command. This would give better performance as well as more control to build standalone programs with UI. - Add LiveSession helper (perf_live.py) to enable live event collection directly from Python using perf.evlist and perf.parse_events. perf stat: - Add --hide-zero-events option to suppress zero-count events - Reject conflicting --field-separator and --json-output options - Fix duplicate event output with --for-each-cgroup perf sched latency: - Add -H/--histogram and --hist-mode (log|linear) options to show scheduler wait latency histograms - Add --time option to filter analysis by time span in 'perf sched latency' ARM CoreSight: - Synthesize callchains for instruction samples from CoreSight trace using thread stack ('--itrace=g...') - Support call indentation ('perf script -F +callindent') to display call depth hierarchy on branch samples - Decode ETE (Embedded Trace Extension) exception packets Build system: - Add 'make install-build-deps' target to install required packages - Parallelize JSON and metric pre-computation in jevents.py for faster builds Vendor event/metric updates: - Add Intel Nova Lake events and update tables for existing models - Update AMD Zen 5 and Zen 6 core events - Update Arm64 Tegra410 metrics and PowerPC hcalls Internal changes and fixes: - Harden trace-event and synthetic event parsing against corrupted data - Fix unwinding of multi-threaded processes in libdw unwinder - Fix memory leaks in various commands and python bindings - Speed up 'perf test' shell tests" * tag 'perf-tools-for-v7.3-2026-08-21' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools: (232 commits) perf vendor events arm64: Fix Tegra410 Olympus event 0x0197 perf vendor events arm64: fix swapped MetricGroup for Tegra410 L1 prefetcher metrics perf evlist: Warn when 'sleep' workload is used without system-wide (-a) option perf c2c: document function view in perf-c2c man page perf c2c: add function view browser UI and cacheline detail perf c2c: build and finalize the function view hierarchy perf c2c: add function view hierarchy entry creation perf c2c: add function view stats merge and memory management perf c2c: add HPP list parsing for function view columns perf c2c: add column rendering for function view perf c2c: add function view model skeleton perf c2c: extract shared data structures into util/c2c.h perf test sample-parsing: Validate PERF_FORMAT_GROUP values without LOST perf dso: Replace assert with runtime check in dso__read_symbol() perf dso: Guard against cache underflow on short reads in dso_cache__memcpy() perf dso: Use stored fd error instead of stale errno in file_read() and file_size() perf dso: Guard close() against invalid fd in dso__decompress_kmodule_path() perf dso: Guard against errno==0 when dso__get_filename() returns NULL perf build: install-build-deps: add RHEL family devel package mapping perf build: Remove leftover feature tests for removed cxx and clang support ...
2026-08-22Merge tag 'firewire-updates-7.3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 Pull firewire updates from Takashi Sakamoto: "Error handling, a potential bug fix, and KUnit tests: - Handle failures when generating the contents of the configuration ROM with parameters supplied by in-kernel implementations such as unit drivers (Sreeraj S Kurup) - Fix potential memory leak when an invalid self-ID sequence causes an error while building the internal node tree (Abdun Nihaal) KUnit tests have been added to trigger this case" * tag 'firewire-updates-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: core: fix memory leak in error path of build_tree() firewire: core: validate parent port count before allocating nodes in build_tree() firewire: core: consolidate port counting in build_tree() firewire: core: add KUnit tests for failure of tree building firewire: core: add KUnit tests for successful tree building firewire: core: add KUnit test skeleton for node tree firewire: core: validate sub-block lengths in fw_core_add_descriptor() firewire: core: validate overall descriptor length in fw_core_add_descriptor()
2026-08-22tracing: Fix logged instance name on creation failureVincent Donnefort
When boot instance creation fails, the kernel incorrectly logs "(null)" as the instance name because strsep() consumes curr_str entirely during parsing. Print the properly parsed name variable instead. And while at it log the error code. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260807085423.4175161-1-vdonnefort@google.com Fixes: cb1f98c5e574 ("tracing: Add creation of instances at boot command line") Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Vincent Donnefort <vdonnefort@google.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-08-22Merge tag 'rust-i2c-for-7.3' into i2c/i2cAndi Shyti
i2c: rust: mark I2cAdapter methods as inline A single cleanup for the Rust I2C abstractions, targeting 7.3. `I2cAdapter::get`, `inc_ref`, and `dec_ref` are trivial wrappers around `i2c_get_adapter`/`i2c_put_adapter` and were showing up as their own symbols in the build. Mark them `#[inline]` so they get folded into their callers instead. Signed-off-by: Igor Korotin <igor.korotin@linux.dev> * tag 'rust-i2c-for-7.3': i2c: rust: mark I2cAdapter methods as inline
2026-08-22i2c: rust: mark I2cAdapter methods as inlineNicolás Antinori
When building the kernel using llvm-19.1.7-rust-1.85.0-x86_64, the following symbols are generated: $ nm vmlinux | grep ' _R'.*I2cAdapter | rustfilt ffffffff817ff380 T <kernel::i2c::I2cAdapter>::get ffffffff817ff400 T <kernel::i2c::I2cAdapter as kernel::sync::aref::AlwaysRefCounted>::dec_ref ffffffff817ff3e0 T <kernel::i2c::I2cAdapter as kernel::sync::aref::AlwaysRefCounted>::inc_ref However, these Rust symbols are trivial wrappers around the `i2c_get_adapter` and `i2c_put_adapter` functions. It doesn't make sense to go through a trivial wrapper for these functions. Link: https://github.com/Rust-for-Linux/linux/issues/1145 Suggested-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Nicolás Antinori <nico.antinori.7@gmail.com> Reviewed-by: Onur Özkan <work@onurozkan.dev> Reviewed-by: Igor Korotin <igor.korotin@linux.dev> Signed-off-by: Igor Korotin <igor.korotin@linux.dev>
2026-08-21sched_ext: Sync common and compat headers from the scx repoTejun Heo
Sync common.bpf.h, compat.bpf.h and compat.h with the scx repo, which accumulated the following: - __COMPAT_read_enum() can now recover 64-bit scx enum values from kernel BTF generated without BTF_KIND_ENUM64 support (pahole < 1.24 or --skip_encoding_btf_enum64, e.g. COS/GKE kernels), substituting values from the build-time vmlinux.h cross-checked against the low 32 bits the kernel does provide. - is_migration_disabled() no longer assumes the BPF prolog always disables migration. Since 8e4f0b1ebcf2 ("bpf: use rcu_read_lock_dont_migrate() for trampoline.c") the prolog only does so under CONFIG_PREEMPT_RCU, so the old current-task test under-reported on v6.18+ !PREEMPT_RCU kernels. A runtime probe on bpf_scx_reg() handles older kernels with backported trampoline behavior. - __COMPAT_scx_bpf_dsq_peek() is gated behind kernel v7.1 where 2f2ea7709266 ("sched_ext: Use dsq->first_task instead of list_empty() in dispatch_enqueue() FIFO-tail") fixed the kfunc spuriously returning NULL on non-empty FIFO DSQs, and the new scx_bpf_reenqueue_local_from_anywhere() provides a callable-from-anywhere reenqueue which prefers the generic scx_bpf_dsq_reenq(). Both were first posted by Gavin Guo and Changwoo Min and are picked up here with the review feedback folded in. - __COMPAT_scx_bpf_cpu_curr() and the scx_bpf_cpu_rq() declaration are restored. Schedulers built from these headers still run on pre-v6.18 kernels where scx_bpf_cpu_curr() does not resolve and the scx_bpf_cpu_rq() fallback still exists. - scx_clock_task() and scx_clock_pelt() document their stale-read behavior for remote idle CPUs under NO_HZ_IDLE. Link: https://lore.kernel.org/all/20260817143126.562923-1-changwoo@igalia.com Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-21sched_ext: Sync tools autogen enum headers from the scx repoTejun Heo
Regenerate enum_defs.autogen.h against the current tree, picking up the dispatch verdict enums and dropping the marker for the removed SCX_RQ_IN_BALANCE. Add enums_abi.autogen.h, a table of 64-bit scx enumerator values generated from vmlinux.h, used as the substitution source when the running kernel's BTF truncates 64-bit enum values to 32 bits. Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-21f2fs: fix to propagate error from f2fs_sync_fs()Chao Yu
So that caller can detect any failure from f2fs_sync_fs(). Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-08-21f2fs: return symlink writeback errorsWenjie Qi
F2FS writes long symlink data with page_symlink() and then flushes the symlink mapping to reduce the chance of exposing a broken symlink. That flush result is currently ignored. If the writeback fails, symlink() still returns success even though the symlink is not durable and the same operation can already surface -EIO through syncfs(). Return the writeback error to userspace and skip the dirsync flush once the symlink data flush has failed. Fixes: d0cae97cb600 ("f2fs: flush symlink path to avoid broken symlink after POR") Cc: stable@kernel.org Signed-off-by: Wenjie Qi <qiwenjie@xiaomi.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-08-21f2fs: fix error handling on device alias check in rename and unlinkDaeho Jeong
In f2fs_rename() and f2fs_unlink(), directly returning -EPERM when encountering a device aliasing file bypasses the cleanup path. Fix this by setting err to -EPERM and jumping to the proper cleanup labels (out_dir and out) instead of returning immediately. Reported-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Daeho Jeong <daehojeong@google.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-08-21f2fs: fix to reset all pinned status during fggcChao Yu
Otherwise, the pinned status may affect latter flow of fggc. Cc: stable@kernel.org Fixes: 9703d69d9d15 ("f2fs: support file pinning for zoned devices") Cc: Daeho Jeong <daehojeong@google.com> Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-08-21f2fs: use f2fs_{down, up}_(read, write}_trace() for nat_tree_lockChao Yu
Under heavy workloads or during background GC/fallocate operations, nat_tree_lock can experience high lock contention between background readers (e.g. f2fs_get_node_info() in gc_data_segment) and writers (e.g. flush_nat_entries, set_node_addr, shrinker). [375067.327986][T13777] schedule+0x4c/0x114 [375067.327997][T13777] f2fs_get_node_info+0x438/0x5c4 [375067.328002][T13777] f2fs_get_inode_page+0x1e0/0x3f0 [375067.328013][T13777] f2fs_iget+0x88/0x1180 [375067.328024][T13777] f2fs_lookup+0x168/0x3a8 [375067.328035][T13777] path_openat+0xa28/0x1b04 [375067.328046][T13777] do_filp_open+0xac/0x130 [375067.328056][T13777] do_sys_openat2+0x140/0x21c [375067.328066][T13777] __arm64_sys_openat+0x70/0x9c [375067.330299][T13777] schedule+0x4c/0x114 [375067.330310][T13777] schedule_preempt_disabled+0x24/0x40 [375067.330321][T13777] rwsem_down_write_slowpath+0x3b4/0x9d0 [375067.330332][T13777] down_write+0x98/0x170 [375067.330343][T13777] set_node_addr+0x74/0x4b4 [375067.330354][T13777] f2fs_new_node_page+0xb0/0x280 [375067.330444][T13777] f2fs_new_inode_page+0x3c/0x64 [375067.330455][T13777] f2fs_init_inode_metadata+0x4c/0x47c [375067.330461][T13777] f2fs_add_regular_entry+0x258/0x5b8 [375067.330471][T13777] f2fs_add_dentry+0x100/0x158 [375067.330476][T13777] f2fs_do_add_link+0x84/0x140 [375067.330487][T13777] f2fs_create+0xec/0x250 [375067.331759][T13777] schedule+0x4c/0x114 [375067.331770][T13777] f2fs_down_read+0x9c/0xc4 [375067.331781][T13777] f2fs_need_inode_block_update+0x20/0x10c [375067.331792][T13777] f2fs_do_sync_file+0x478/0x830 [375067.331802][T13777] f2fs_sync_file+0x2c/0x40 This patch converts nat_tree_lock to use the f2fs_{down,up}_{read,write}_trace infrastructure. Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-08-21dt-bindings: input: Add Qualcomm SPMI PMIC hapticsFenglin Wu
Add binding document for the haptics module inside Qualcomm PMIC PMIH0108. Assisted-by: Claude:claude-4-8-opus Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com> Link: https://patch.msgid.link/20260806-qcom-spmi-haptics-v6-1-19fcecd5204f@oss.qualcomm.com [robh: Drop example] Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-08-21ASoC: fix unmet dependencies on PPC_BESTCOMM and SND_SOC_AC97_BUSJulian Braha
SND_MPC52xx_SOC_PCM030 and SND_MPC52xx_SOC_EFIKA both select SND_SOC_MPC5200_AC97 without ensuring its dependency on PPC_BESTCOMM is met. This causes unmet dependencies such as: WARNING: unmet direct dependencies detected for SND_SOC_MPC5200_AC97 Depends on [n]: SOUND [=m] && SND [=m] && SND_SOC [=m] && SND_POWERPC_SOC [=m] && PPC_BESTCOMM [=n] Selected by [m]: - SND_MPC52xx_SOC_PCM030 [=m] && SOUND [=m] && SND [=m] && SND_SOC [=m] && SND_POWERPC_SOC [=m] && PPC_MPC5200_SIMPLE [=y] In v1, Rosen pointed out that the import of "mpc5200_dma.h" is actually unnecessary, and Arnd suggested that the 'select' of SND_SOC_MPC5200_AC97 be changed to 'depends on'. This resolves all 3 unmet dependencies. These unmet dependency bugs were detected by kconfirm, a static analysis tool for Kconfig. Fixes: a9262c4fd404 ("ASoC: Support for AC97 on Phytec pmc030 base board.") Fixes: 6ffee43ecf8b ("ASoC: Fabric bindings for STAC9766 on the Efika") Suggested-by: Arnd Bergmann <arnd@arndb.de> Suggested-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Julian Braha <julianbraha@gmail.com> Link: https://patch.msgid.link/20260821175410.179631-1-julianbraha@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-21ASoC: tac5xx2-sdw: update default regmap registersNiranjan H Y
* At boot time, when the registers are accessed by asoc layer while trying to enable a DAPM path, while the device is still being attached, -EBUSY error will be thown by regmap_read and regmap_udpate_bits. Because the regmap will be in cache only mode. Add default values for these registers so that, the cached values are returned instead of error. * Also remove writing default values once again for first attach. Signed-off-by: Niranjan H Y <niranjan.hy@ti.com> Link: https://patch.msgid.link/20260820115114.1203-3-niranjan.hy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-21ASoC: tac5xx2-sdw: Rename gain and volume macrosNiranjan H Y
Rename gain and volume macros to match the hardware intent. Currently, both TAC_SDCA_CHANNEL_GAIN and TAC_SDCA_CHANNEL_VOLUME are defined as 0x02. Keep only TAC_SDCA_CHANNEL_VOLUME and reposition TAC_SDCA_CHANNEL_GAIN to 0x0B. Remove the now-redundant TAC_SDCA_MASTER_GAIN alias (also 0x0B), replacing its single use with TAC_SDCA_CHANNEL_GAIN. Signed-off-by: Niranjan H Y <niranjan.hy@ti.com> Link: https://patch.msgid.link/20260820115114.1203-2-niranjan.hy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-21ASoC: sdw_utils: Set component_name for tac5xx2 codec familyNiranjan H Y
* With component_name set in the codec_info_list DAI entries, "amixer -D hw:<card> info" includes the 'spk' identifier for each tac5xx2 speaker component. This allows userspace to identify the speaker codec at runtime and enables UCM card matching for the tac5xx2 family. * Set component_name for the speaker, mic, and UAJ DAI entries for all tac5xx2 family variants. Signed-off-by: Niranjan H Y <niranjan.hy@ti.com> Link: https://patch.msgid.link/20260820115114.1203-1-niranjan.hy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-21Merge branch 'pci/misc'Bjorn Helgaas
- Fix typos in documentation (D'Orus Tsitera) - Use %pe format specifier to print error pointers so we get symbolic errname when available (Krzysztof Wilczyński) * pci/misc: PCI: Use %pe format specifier to print error pointers Documentation: PCI: Fix sysfs-bus-pci typo
2026-08-21Merge branch 'pci/controller/misc'Bjorn Helgaas
- Use common wait time definitions for PCIe link monitoring instead of defining driver-private duplicates (Thierry Reding) - Add LECARC PMU IDs to the DWC RAS/DES VSEC list so it can take advantage of the existing debugfs support for silicon debug, error injection, and event counters (Brett Zhou) * pci/controller/misc: PCI: dwc: Add PCI ID for LECARC PCIe PMU PCI: Use standard wait times for PCIe link monitoring
2026-08-21Merge branch 'pci/controller/xgene'Bjorn Helgaas
- Drop unnecessary OF node reference (Yuho Choi) * pci/controller/xgene: PCI: xgene: Drop unnecessary OF node reference
2026-08-21Merge branch 'pci/controller/vmd'Bjorn Helgaas
- Support device ID 0x28C1 and assume that BIOS has already enumerated the hierarchy below VMD and stored bus range info for OS to use (Nirmal Patel) - Add support for VMCONFIG BUS_RESTRICT_CFG=3, which makes it possible to enumerate downstream devices on Intel Arrow Lake-HX systems and probably others (Ali Alaei) - Observe _OSC negotiation for VMD hierarchy only when running on bare metal, not when running in a VM (Nirmal Patel) - Add Nova Lake (NVL) and Dunlow (DNL) Device IDs (Szymon Durawa) * pci/controller/vmd: PCI: vmd: Add Nova Lake (NVL) and Dunlow (DNL) Device IDs PCI: vmd: Only copy root bridge _OSC control flags in bare metal OS PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX PCI: vmd: Add feature to scan BIOS-enumerated devices
2026-08-21Merge branch 'pci/controller/tegra264'Bjorn Helgaas
- Distinguish Tegra264 C0 PCIe controller for internal GPU from C1-C5 controllers so the unit address matches the first 'reg' entry (Thierry Reding) - Add Tegra264 Root Port stanzas to prepare for generic WAKE# handling (Thierry Reding) - Add NVIDIA Tegra264 driver (Thierry Reding) * pci/controller/tegra264: PCI: tegra264: Add Tegra264 support dt-bindings: PCI: tegra264: Switch to PCIe Root Port bindings dt-bindings: PCI: tegra264: Strictly distinguish C0 from C1-C5
2026-08-21Merge branch 'pci/controller/rzg3s-host'Bjorn Helgaas
- Add DT binding and driver support for RZ/V2H(P) SoC, which contains two PCIe controllers, configured either as a single x4 link or two independent x2 link controllers (Lad Prabhakar) * pci/controller/rzg3s-host: PCI: rzg3s-host: Add support for RZ/V2H(P) SoC PCI: rzg3s-host: Prepare System Controller handling for multiple controllers PCI: rzg3s-host: Use shared reset controls for power domain resets dt-bindings: PCI: renesas,r9a08g045-pcie: Add RZ/V2H(P) support
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-08 18:24:16 +0000