summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-07-23Merge branch 'drop_monitor-take-care-of-32bit-kernels'Jakub Kicinski1-5/+5
Eric Dumazet says: ==================== drop_monitor: take care of 32bit kernels This series fixes two drop_monitor issues on 32-bit architectures: - Patch 1 uses nla_total_size_64bit() for PC and TIMESTAMP attributes to account for alignment padding added by nla_put_u64_64bit(), avoiding potential skb_over_panic() crashes. - Patch 2 moves u64_stats updates before spin_unlock_irqrestore(), ensuring local interrupts are disabled to prevent seqcount corruption from nested interrupts in probe context. ==================== Link: https://patch.msgid.link/20260722141743.3266924-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23drop_monitor: perform u64_stats updates under IRQ-disabled sectionEric Dumazet1-2/+2
In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update. Fixes: e9feb58020f9 ("drop_monitor: Expose tail drop counter") Fixes: 5e58109b1ea4 ("drop_monitor: Add support for packet alert mode for hardware drops") Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260722141743.3266924-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23drop_monitor: fix size calculations for 64-bit attributesEric Dumazet1-3/+3
net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations. Fixes: ca30707dee2b ("drop_monitor: Add packet alert mode") Fixes: 5e58109b1ea4 ("drop_monitor: Add support for packet alert mode for hardware drops") Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260722141743.3266924-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOADYehyeong Lee1-6/+2
net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction. Fixes: ca30707dee2b ("drop_monitor: Add packet alert mode") Fixes: 5e58109b1ea4 ("drop_monitor: Add support for packet alert mode for hardware drops") Suggested-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr> Link: https://patch.msgid.link/20260722122817.5548-1-yhlee@isslab.korea.ac.kr Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23Merge branch 'mptcp-misc-fixes-for-v7-2-rc5'Jakub Kicinski4-21/+27
Matthieu Baerts says: ==================== mptcp: misc fixes for v7.2-rc5 Here are various unrelated fixes: - Patch 1: decrement extra subflows counter in case of errors with passive MP_JOIN. A fix for v5.7. - Patch 2: fix use-after-free in userspace_pm_get_local_id. A fix for v5.19. - Patch 3: fix stale skb->sk reference on subflow close, in case of concurrent read operation. A fix for v6.19. - Patch 4: wait on the correct port in the userspace_pm.sh selftest. A fix for v6.19. - Patch 5: fix a BUILD_BUG_ON on legacy ARM config. A fix for v7.1. ==================== Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-0-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23mptcp: fix BUILD_BUG_ON on legacy ARM configMatthieu Baerts (NGI0)1-4/+1
The 0-day bot managed to find kernel configs that cause build failures, e.g. when using the StrongARM SA1100 target (ARMv4). On such legacy ARM architecture, all structures are apparently aligned to 32 bits, causing build issue here. Indeed, on such architecture, 'flags' size is not equivalent to sizeof(u16) as expected, but to sizeof(u32). Instead, use memset(). It was not used before to ensure a simple clear operation was used by the compiler. But at the end, it shouldn't matter, and the compiler should optimise this to the same operation with or without memset() when -O above 0 is used. So let's switch to memset() to fix this issue, and reduce this complexity. Fixes: 5e939544f9d2 ("mptcp: fix uninit-value in mptcp_established_options") Cc: stable@vger.kernel.org Suggested-by: Frank Ranner <frank.ranner@intel.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202605312026.Srgsz7Tp-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202607031100.upQfRZTM-lkp@intel.com/ Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-5-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23selftests: mptcp: userspace_pm: fix undefined variable portGeliang Tang1-1/+1
In make_connection(), the variable "port" is used but never defined. This leads to an empty argument being passed to wait_local_port_listen(), causing "printf: : invalid number" errors: # INFO: Init # 01 Created network namespaces ns1, ns2 [ OK ] # INFO: Make connections # ./../lib.sh: line 651: printf: : invalid number # 02 Established IPv4 MPTCP Connection ns2 => ns1 [ OK ] # INFO: Connection info: 10.0.1.2:59516 -> 10.0.1.1:50002 # ./../lib.sh: line 651: printf: : invalid number # 03 Established IPv6 MPTCP Connection ns2 => ns1 [ OK ] Fix it by using the correctly defined variable "app_port", which holds the appropriate port number for the connection. Fixes: 39348f5f2f13 ("selftests: mptcp: wait for port instead of sleep") Cc: stable@vger.kernel.org Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-4-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23mptcp: fix stale skb->sk reference on subflow closeKalpan Jani1-14/+19
The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely. Fixes: ee458a3f314e ("mptcp: introduce mptcp-level backlog") Cc: stable@vger.kernel.org Suggested-by: Paolo Abeni <pabeni@redhat.com> Reported-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/621 Signed-off-by: Kalpan Jani <kalpan.jani@mpiricsoftware.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-3-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23mptcp: pm: userspace: fix use-after-free in get_local_idGeliang Tang1-2/+5
In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] <IRQ> [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a "not found" sentinel. Fixes: f012d796a6de ("mptcp: check addrs list in userspace_pm_get_local_id") Cc: stable@vger.kernel.org Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Tested-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-2-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23mptcp: decrement subflows counter on failed passive joinChenguang Zhao1-0/+1
mptcp_pm_allow_new_subflow() increments extra_subflows before __mptcp_finish_join() on the passive MP_JOIN path. In case of race conditions, the subflow is dropped without calling mptcp_close_ssk(), so the counter is not rolled back. Call mptcp_pm_close_subflow() when the join completion fails to decrement the subflows counter. Fixes: 10f6d46c943d ("mptcp: fix race between MP_JOIN and close") Cc: stable@vger.kernel.org Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-1-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23selftests/sched_ext: Handle sleeping task affinity changes in numa testKuba Piecuch1-1/+12
When a sleeping task's affinity is changed, task_cpu(p) can be outside of p->cpus_ptr until after select_task_rq() selects a new runqueue for the task during wakeup. Thus, the task's NUMA node determined by numa_select_cpu() can be completely outside of the task's cpumask, leading to scx_pick_{idle,any}_cpu_node() failing to find an eligible CPU and returning -EBUSY. This leads to the numa.bpf.c scheduler abnormally exiting with the following message in dmesg: sched_ext: numa: invalid CPU -16 scx_bpf_cpu_node+0x120/0x190 bpf_prog_0a34b8e0f515771f_numa_select_cpu+0x108/0x14e bpf__sched_ext_ops_select_cpu+0x4f/0xb4 select_task_rq_scx+0xb0/0x210 select_task_rq+0xa0/0xd0 __try_to_wake_up+0x196/0x650 complete_all+0x76/0x100 migration_cpu_stop+0x22b/0x300 cpu_stopper_thread+0xc1/0x180 smpboot_thread_fn+0x16b/0x230 kthread+0x2d7/0x350 ret_from_fork+0x1c2/0x350 ret_from_fork_asm+0x1a/0x30 Make numa_select_cpu() robust against this case by returning @prev_cpu if no CPU could be found in the selected NUMA node _and_ we have reason to believe that the task's affinity was changed while it was sleeping. Fixes: 5ae5161820e5 ("selftests/sched_ext: Add NUMA-aware scheduler test") Signed-off-by: Kuba Piecuch <jpiecuch@google.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-07-23Input: xpad - add support for ZENAIM LEVERLESSKyohei Kadota1-0/+2
Add the VID/PID for the ZENAIM LEVERLESS controller to xpad_device and the VID to xpad_table. Signed-off-by: KADOTA, Kyohei <lufia@lufia.org> Link: https://patch.msgid.link/CAFMepckDUuOHiDDVVhUYc-UqJMeCqrWSfCuxbJ2x2sGgdDD4nw@mail.gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-07-23ASoC: dt-bindings: sound: spacemit,k1-i2s: allow 6 clocks for K3 i2s1Troy Mitchell1-20/+44
The K3 I2S controllers normally use the published 7-clock layout: sysclk, bclk, bus, func, sysclk_div, c_sysclk, c_bclk However, K3 i2s1 has no dedicated sysclk divider and therefore uses a 6-clock layout: sysclk, bclk, bus, func, c_sysclk, c_bclk Describe the 4-clock K1 and both K3 layouts as separate tuples. Lower the K3 minimum from 7 to 6 clocks while preserving the existing 7-clock ordering. Fixes: 6bc6b28c0314 ("ASoC: dt-bindings: add SpacemiT K3 SoC compatible") Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Link: https://patch.msgid.link/20260721-kx-i2s-dts-v1-2-d22cb6cfaab5@linux.spacemit.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-23ASoC: spacemit: rename clock inputs to match bindingTroy Mitchell1-8/+8
The driver requests the per-controller SSPA bus and functional clocks as "sspa_bus" and "sspa", but the device tree binding (spacemit,k1-i2s) specifies them as "bus" and "func". As a result, any DT written against the published binding fails to probe. There are currently no in-tree DT users referencing these names, so rename the clock inputs in the driver to match the binding rather than changing the binding. While at it, rename the matching struct member sspa_clk to func_clk for consistency with the new clock-names. Fixes: fce217449075 ("ASoC: spacemit: add i2s support for K1 SoC") Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Link: https://patch.msgid.link/20260721-kx-i2s-dts-v1-1-d22cb6cfaab5@linux.spacemit.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-23rcu-tasks: Remove smp_mb() in rcu_spawn_tasks_kthread_generic()Zqiang1-1/+0
For the smp_mb() after kthread_run() in rcu_spawn_tasks_kthread_generic() from these commits: 'commit eacd6f04a133 ("rcu-tasks: Move Tasks RCU to its own file")' 'commit 84a8f446ffd7 ("rcu: Defer rcu_tasks_kthread() creation till first call_rcu_tasks()")' the memory order pairing as follows: rcu_spawn_tasks_kthread() ->t = kthread_run(rcu_tasks_kthread, ...); ->smp_mb(); /* Ensure others see full kthread. */ ->WRITE_ONCE(rcu_tasks_kthread_ptr, t); call_rcu_tasks() ->if (READ_ONCE(rcu_tasks_kthread_ptr)) ->wake_up(&rcu_tasks_cbs_wq) ->try_to_wake_up() lock pi_lock ->smp_mb__after_spinlock() //see full kthread Because the 'commit d119357d0743 ("rcu-tasks: Treat only synchronous grace periods urgently")' moved the kthread_ptr assignment into the rcu_tasks_kthread() function, the following memory order pairings are sufficient: The runq's raw_spinlock/unlock(or smp_mb__after_spinlock()) from wake_up_process() in kthread_run() and __schedule() provides memory order barrier when the kthread is first scheduled, this ensures the kthread's func observes all of the kthread's initialization. The kthread's smp_store_release(&rtp->kthread_ptr, ...) in rcu_tasks_kthread() and smp_load_acquire(&rtp->kthread_ptr) in call_rcu_tasks_generic() compose release/acquire pairing, the cumulativity of smp_store_release() propagates visibility of the kthread's initialization through the scheduler chain. This commit therefore remove smp_mb() in rcu_spawn_tasks_kthread_generic(). Signed-off-by: Zqiang <qiang.zhang@linux.dev> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-23rcu-tasks: Apply READ_ONCE() and WRITE_ONCE() to fix data racePaul E. McKenney1-2/+8
Now that rcutorture tests readers from interrupt handlers, KCSAN spotted an additional data race. This commit therefore fixes it by applying READ_ONCE() and WRITE_ONCE(). Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-23rcu-tasks: Dump rcu tasks status when the boot-test failedZqiang1-0/+5
This commit adds a dump RCU task status function to rcu tasks tests, used to obtain more information to help debug when the RCU tasks boot-time tests failed. Signed-off-by: Zqiang <qiang.zhang@linux.dev> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-23rcu-tasks: Remove unused struct rcu_tasks's->n_ipis_fails variablesZqiang1-4/+2
The RCU tasks trace has been reimplemented by 'commit c27cea4416a3 ("rcu: Re-implement RCU Tasks Trace in terms of SRCU-fast")', the rcu_tasks structure's->n_ipis_fails is no longer used, this commit therefore remove it. Signed-off-by: Zqiang <qiang.zhang@linux.dev> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-23rcu: clear defer_qs_pending in deferred-QS bail when nesting > 0Joel Fernandes1-1/+27
Paul McKenney noted that a softirq (or irq_work) handler arming for a deferred QS can fire and find rcu_preempt_depth() > 0 -- the task is still inside its outer reader, so rcu_preempt_need_deferred_qs() bails without reporting the QS. At that point the queued mechanism has been consumed but ->defer_qs_pending stays in DEFER_QS_PENDING. In the meantime, the only remaining path back to a quiescent state on this CPU may be a local_irq_disable()/_enable() pair that does not call preempt_check_resched() (it is just `sti`/`cli`). patch 6's unconditional set_need_resched_current() makes need_resched true, but without an irq_work being raised the next outer rcu_read_unlock_special() hits the P-gate at the arming code: if (rdp->defer_qs_pending != DEFER_QS_PENDING) { rdp->defer_qs_pending = DEFER_QS_PENDING; irq_work_queue_on(...); // <-- skipped } so no irq_work is queued for the hardirq-exit preempt_schedule_irq() path either. The deferred QS now waits until the next timer tick (or similar preempt-safe boundary), needlessly extending expedited grace period latency. Clear ->defer_qs_pending in the bail-out path of rcu_preempt_deferred_qs() when rcu_preempt_depth() > 0. The recursion guard semantics introduced by commit b41642c87716 ("rcu: Fix rcu_read_unlock() deadloop due to IRQ work"). The clear is also safe against fresh recursion at this exact program point: rcu_preempt_depth() > 0 guarantees we are still inside an outer reader, so any inner rcu_read_unlock() from tracing infrastructure brings nesting back to outer (>0), never to 0. The slow path of rcu_read_unlock_special() is structurally unreachable under that condition, so no recursive raise_softirq_irqoff()/irq_work_queue_on() can be triggered by the clear. Essentially, the mechanism will work to prevent the following recursion which Xiongfeng had previously reported: irq_exit() -> __irq_exit_rcu() -> tick_irq_exit() -> tick_nohz_irq_exit() -> tick_nohz_stop_sched_tick() -> trace_tick_stop() // BPF prog hooked here -> rcu_read_unlock_special() -> irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu) // self-IPI re-enters irq_exit Reported-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-23rcu: introduce rcu_defer_qs_clear() helperJoel Fernandes2-2/+7
Currently rdp->defer_qs_pending transitions from DEFER_QS_PENDING to DEFER_QS_IDLE at two sites: rcu_preempt_deferred_qs_irqrestore() and rcu_preempt_deferred_qs_handler() (depth>0 reset). Both write the IDLE value directly. Introduce a single inline helper rcu_defer_qs_clear() in tree.h and route both sites through it. This becomes the single PENDING->IDLE transition point for upcoming work. Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-23doc: RCU: Fix bracketsManuel Ebner4-4/+4
Remove needless brackets and add missing brackets. Signed-off-by: Manuel Ebner <manuelebner@mailbox.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-23doc: RCU: Adopt new coding style of type-aware kmalloc-family - part 2/2Manuel Ebner1-2/+2
Update Documentation/RCU/* to suggest using the new type-aware kmalloc_obj() per commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() and family") p = kmalloc(...); -> p = kmalloc_obj(...); Signed-off-by: Manuel Ebner <manuelebner@mailbox.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-23rcu: Mark __rcu_access_pointer() as context_unsafe()Paul E. McKenney1-2/+2
A simple comparison of a pointer returned by rcu_access_pointer() results in a context-analysis warning for lockless inspection of the RCU-protected (also known as __rcu-protected) pointer. This can be suppressed by placing context_unsafe() calls around calls rcu_access_pointer(), but this is messy and distracting. This commit therefore wraps the underlying __rcu_access_pointer() macro with a call to context_unsafe(), thereby informing the context-analysis code that rcu_access_pointer() may safely be invoked outside of an RCU read-side critical section. Reported-by: Christoph Hellwig <hch@lst.de> Suggested-by: Marco Elver <elver@google.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Tested-by: Nilay Shroff <nilay@linux.ibm.com> Reviewed-by: Marco Elver <elver@google.com>
2026-07-23rcu: Use task_state_to_char() in stall-warning printsKunwu Chan1-6/+6
RCU stall warnings currently print task states as raw hexadecimal values, requiring developers to manually decode them. Use task_state_to_char() so that stall warnings show the same symbolic task-state representation used elsewhere in the kernel. For example: ->state=0x402 becomes ->state=I ->state=0x0 becomes ->state=R ->state=0x2 becomes ->state=D This improves readability while preserving the underlying diagnostic information. Suggested-by: Zqiang <qiang.zhang@linux.dev> Co-developed-by: Wang Lian <lianux.mm@gmail.com> Signed-off-by: Wang Lian <lianux.mm@gmail.com> Signed-off-by: Kunwu Chan <kunwu.chan@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-23rcu: Add RCU_GET_STATE_NOT_TRACKED for subsystems without expedited GPsPuranjay Mohan2-3/+13
SRCU and Tasks RCU do not track expedited grace periods. When their callback state is checked via poll_state_synchronize_rcu_full(), the uninitialized or zeroed exp field could cause false-positive completion detection. This commit adds an RCU_GET_STATE_NOT_TRACKED sentinel value (0x2) that these subsystems can place into exp to indicate that expedited GP tracking is not applicable. The expedited sequence check in poll_state_synchronize_rcu_full() is guarded to skip entries marked with this sentinel. This is needed to allow rcu_segcblist_advance() and rcu_accelerate_cbs() to work with both normal and expedited grace periods via get_state_synchronize_rcu_full() and poll_state_synchronize_rcu_full(). Reviewed-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-23rcu/segcblist: Track segment grace periods with struct rcu_gp_seqPuranjay Mohan6-37/+46
Change the type of the per-segment ->gp_seq[] array in struct rcu_segcblist from unsigned long to struct rcu_gp_seq. This prepares the callback tracking infrastructure to record both normal and expedited grace periods per segment. The rcu_segcblist_nextgp(), rcu_segcblist_advance(), and rcu_segcblist_accelerate() helpers now take a struct rcu_gp_seq * instead of an unsigned long, and all callers use the .norm field for comparisons and assignments. The SRCU and Tasks RCU wrappers construct a struct rcu_gp_seq with only .norm set and forward to the core helpers. No functional change: only the .norm field is used. Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-23rcu/segcblist: Factor out rcu_segcblist_advance_compact() helperPuranjay Mohan1-18/+32
This commit extracts the tail-pointer cleanup and segment compaction logic from rcu_segcblist_advance() into a new static helper function, rcu_segcblist_advance_compact(). This shared logic will be reused by the upcoming srcu_segcblist_advance() standalone implementation, which cannot call the core rcu_segcblist_advance() because that function will use RCU-specific globals. No functional change. Reviewed-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-23rcu/segcblist: Add SRCU and Tasks RCU wrapper functionsPuranjay Mohan4-11/+23
Add srcu_segcblist_advance() and srcu_segcblist_accelerate() wrappers that forward to the core rcu_segcblist_advance() and rcu_segcblist_accelerate() functions, and switch all SRCU (srcutree.c) and Tasks RCU (tasks.h) callers to use these wrappers. This isolates SRCU and Tasks RCU from upcoming changes to the core advance/accelerate functions, which will switch to struct rcu_gp_seq for dual normal/expedited GP tracking. Because SRCU and Tasks RCU use only normal GP sequences, their wrappers will maintain the existing unsigned long interface. No functional change. Reviewed-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-23rcu: Rename struct rcu_gp_oldstate to rcu_gp_seqPuranjay Mohan9-100/+100
The polled grace-period state structure rcu_gp_oldstate holds a snapshot of the normal (and, on SMP, expedited) grace-period sequence numbers. Upcoming changes store this structure in the callback segment list, where the "oldstate" name reads poorly: there it represents the grace period a segment is waiting on and is also compared against the current grace-period state. Rename struct rcu_gp_oldstate to the more neutral struct rcu_gp_seq, and shorten its members rgos_norm and rgos_exp to norm and exp. Local variables and parameters of this type are renamed from rgosp/rgos to gsp/gs accordingly. While at it, provide a single definition of the structure in rcupdate.h rather than separate Tiny-RCU and Tree-RCU definitions, and give it the ->exp field unconditionally. Tiny RCU does not track expedited grace periods and leaves ->exp unused, but a single definition that always has ->exp lets the shared callback code in rcu_segcblist.c reference it without CONFIG_SMP guards, including on !SMP builds. No functional change. Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-23rcu: Remove unused rdp parameter from trace_rcu_this_gp()Joel Fernandes2-15/+12
The trace_rcu_this_gp() wrapper forwards only the rcu_node structure's fields and the requested grace-period sequence number to the rcu_future_grace_period tracepoint. Its rcu_data pointer parameter has no users, but every one of the ten call sites must nevertheless come up with an rcu_data pointer to pass in. Remove the parameter and update all callers. This also allows rcu_future_gp_cleanup() to drop the local rcu_data pointer that existed solely to feed this trace call. No functional change. Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-23Input: edt-ft5x06 - ignore contacts with an out-of-range slot idAlexandre Hamamdjian1-0/+2
The per-contact slot id is taken from the top nibble of the third report byte, so it can be any value from 0 to 15. The driver only allocates max_support_points MT slots (2 to 10 depending on the variant), so a report that carries an id at or above that count - be it a genuinely higher-numbered contact or a corrupted byte - is outside the range the input core was told about. input_mt_slot() silently ignores an ABS_MT_SLOT beyond num_slots and leaves the current slot unchanged, so the following input_mt_report_slot_state()/touchscreen_report_pos() pair is applied to whichever slot happened to be selected last, reporting the contact at the wrong position. Skip such entries instead. Signed-off-by: Alexandre Hamamdjian <azkali.limited@gmail.com> Link: https://patch.msgid.link/20260723-b4-ft5426-v2-1-cd2bed168051@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-07-23Merge branch 'mlx5-next' of ↵Jakub Kicinski4-32/+25
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux Tariq Toukan says: ==================== mlx5-next updates 2026-07-22 * 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux: net/mlx5: Add PSP related fields to the mlx5_ifc net/mlx5: Drop redundant esw_cap, reuse e_switch_cap ==================== Link: https://patch.msgid.link/20260722071030.1693021-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23scftorture: Make invoker threads actually wait for all threads to startJoel Fernandes1-1/+1
Each scftorture_invoker() thread decrements n_started, which is initialized to the number of threads, and is then supposed to wait until all of its siblings have also checked in before starting the test proper. However, the wait loop is guarded by !atomic_dec_return(&n_started), which is true only for the final thread to arrive, and by then n_started is already zero, so the final thread does not wait either. The side-effect (possibly positive) is that no thread ever waits and the start-synchronization barrier is dead code, with early threads beginning to hammer smp_call_function*() while later threads are still being spawned. Invert the test so that every thread other than the last spins until n_started reaches zero, making the threads start testing together as intended. The existing torture_must_stop() check in the wait loop continues to bound the wait during shutdown. We can also drop the spinning entirely if the intent is to leave it as dead code, however for the current intent, this patches fixes the code. Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-23scftorture: Count single_rpc offline failures in statistics outputJoel Fernandes1-0/+1
scf_torture_stats_print() aggregates each invoker thread's counters into a local scf_statistics structure before printing, but the n_single_rpc_ofl field is missing from the aggregation loop. As a result, the "single_rpc_ofl" value printed in the statistics line is always zero, even when smp_call_function_single() invocations for the RPC test have failed due to offline CPUs and been counted by the invoker threads. Add the missing accumulation so that the printed value reflects the actual counts. Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-23mac802154: hold an interface reference across the scan workerIbrahim Hashimov1-0/+11
mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit. Fixes: 57588c71177f ("mac802154: Handle passive scanning") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov <security@auditcode.ai> Link: https://patch.msgid.link/20260721211228.34578-1-security@auditcode.ai Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23sctp: don't free the ASCONF's own transport in DEL-IP processingJun Yang1-0/+6
sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport. Fixes: 42e30bf3463c ("[SCTP]: Handle the wildcard ADD-IP Address parameter") Cc: stable@kernel.org Signed-off-by: Jun Yang <junvyyang@tencent.com> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/tencent_73762ED1DF08CC9D5F5F61954B01350CFE0A@qq.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23phonet: check register_netdevice_notifier() error in phonet_device_init()Minhong He1-6/+24
phonet_device_init() registers a netdevice notifier before calling phonet_netlink_register(), but does not check whether notifier registration succeeded. On failure, netlink setup still proceeds and init may return success without the notifier in place. Also, the existing phonet_netlink_register() failure path called phonet_device_exit(), which runs rtnl_unregister_all() even though rtnl_register_many() already unwound any partial registration. Calling the full exit helper on a partial init is not correct. Check each registration error, including proc_create_net(), and unwind only the steps that have succeeded so far, in reverse order. Signed-off-by: Minhong He <heminhong@kylinos.cn> Link: https://patch.msgid.link/20260721093956.162617-1-heminhong@kylinos.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23phonet: pep: fix use-after-free in pep_get_sb()Breno Leitao1-0/+2
pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one. Fixes: 9641458d3ec4 ("Phonet: Pipe End Point for Phonet Pipes protocol") Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260721-phonet_get_sb_uaf-v1-1-95fd7881cc4e@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23wifi: iwlwifi: bump core version for BZ/SC/DRMiri Korenblit3-3/+3
Start supporting Core 107 FW on these devices. Link: https://patch.msgid.link/20260723142324.ed92b1d7f927.I6dd10d2f9a04a36751aea9e238fecfa62fe280a6@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-23wifi: iwlwifi: regulatory: add LARI v15 DSM support bitmapPagadala Yesu Anjaneyulu4-4/+21
Firmware API v15 extends LARI config with the DSM function-0 support bitmap, and host must provide this information for regulatory handling. Without this, FW cannot use BIOS-reported DSM capability bits. Add oem_supported_dsm_bitmap to the host LARI config command definition and wire it into regulatory command construction. Populate it from DSM query data and keep backward compatibility by using the pre-v15 command size for command version 14. Behavior change: When DSM function-0 data is available, host includes it in the LARI config command sent to FW; older command versions remain compatible. Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Link: https://patch.msgid.link/20260723142324.c576a8c7560b.I5cc1277d0ef31409f6a3364342a3f35cd9318ceb@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-23bnge/bng_re: fix ring ID widthsVikas Gupta8-41/+39
Firmware requires more than 16 bits to address TX ring IDs for its internal QP management. Widen the associated HSI ring ID fields to 32 bits. The values firmware assigns remain within 24 bits, bounded by the hardware doorbell XID field. The fw_ring_id field belongs to bnge_ring_struct, a common struct shared by all ring types, so widening it to u32 applies uniformly across TX, RX, CP, and NQ rings but firmware assigns values within 16-bit range for all ring types except TX, which requires the wider field. Note that, Thor Ultra hardware has not yet been deployed and no firmware has been released to field, so backward compatibility is not a concern. Fixes: 42d1c54d6248 ("bnge/bng_re: Add a new HSI") Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com> Reviewed-by: Siva Reddy Kallam <siva.kallam@broadcom.com> Reviewed-by: Dharmender Garg <dharmender.garg@broadcom.com> Reviewed-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com> Link: https://patch.msgid.link/20260721063731.2622500-1-vikas.gupta@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23selftests: drv-net: Fix TSO test docPetr Vorel1-1/+1
Replace copy paste from csum.py with a real test purpose. Signed-off-by: Petr Vorel <pvorel@suse.cz> Link: https://patch.msgid.link/20260720215149.631145-2-pvorel@suse.cz Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23selftests: drv-net: Fix csum path in docPetr Vorel1-1/+1
C source was moved in 1d0dc857b5d87. Signed-off-by: Petr Vorel <pvorel@suse.cz> Link: https://patch.msgid.link/20260720215149.631145-1-pvorel@suse.cz Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23ASoC: fsl: mpc5200_dma: use platform helpers and devm cleanupRosen Penev3-45/+20
Convert mpc5200_audio_dma_create() to the managed APIs. Replace the open-coded of_address_to_resource() + devm_ioremap() of the PSC registers with devm_platform_get_and_ioremap_resource(), and irq_of_parse_and_map() with platform_get_irq() (which returns a negative errno instead of 0). Switch the allocation to devm_kzalloc(), the three interrupt requests to devm_request_irq(), and drop the now-unneeded error-path cleanup and the manual teardown in mpc5200_audio_dma_destroy(). The PSC register window is owned solely by this driver, so the new region request from devm_platform_get_and_ioremap_resource() cannot conflict with another claimant, and it is mapped exactly once (no double mapping). The resource pointer is still used (res->start) to compute the FIFO physical address. No functional change; built for powerpc (allmodconfig + CONFIG_SND_SOC_MPC5200_DMA) with LLVM=1 and sound/soc/fsl/mpc5200_dma.o compiles cleanly. Assisted-by: opencode:hy3-free Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260721225936.838299-1-rosenp@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-23tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream()Cen Zhang (Microsoft)1-2/+2
In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe. Fixes: e9f8b10101c6 ("tipc: refactor function tipc_sk_recvmsg()") Fixes: ec8a09fbbeff ("tipc: refactor function tipc_sk_recv_stream()") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Cen Zhang (Microsoft) <blbllhy@gmail.com> Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech> Link: https://patch.msgid.link/20260720214103.47732-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23Merge tag 'ovpn-net-20260720' of https://github.com/OpenVPN/ovpn-net-nextJakub Kicinski4-12/+18
Antonio Quartulli says: ==================== Included fixes: * ensure keepalive timestamps are computed using monotonic source * avoid UAF in unlock_ovpn() when iterating over release_list * fix memleak in selftest tool * ensure reference to peer is acquired before scheduling worker (which may drop the not-yet-taken ref) * fix refcount leak in case of concurrent TX and RX TCP error * fix potential refcount unbalance in case of sock release in P2P mode * tag 'ovpn-net-20260720' of https://github.com/OpenVPN/ovpn-net-next: ovpn: use monotonic clock for peer keepalive timeouts ovpn: fix use after free in unlock_ovpn() selftests/net: ovpn: fix getaddrinfo memory leak in ovpn_parse_remote() ovpn: hold peer before scheduling keepalive work ovpn: fix peer refcount leak in TCP error paths ovpn: avoid putting unrelated P2P peer on socket release ==================== Link: https://patch.msgid.link/20260720144131.3657121-1-antonio@openvpn.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23net: airoha: fix ETS channel derivation in airoha_tc_setup_qdisc_ets()Lorenzo Bianconi1-2/+1
Derive the hardware QoS channel from opt->parent instead of opt->handle in airoha_tc_setup_qdisc_ets(). The ETS qdisc handle is either user-specified or auto-allocated by qdisc_alloc_handle() and bears no relation to the HTB leaf classid that identifies the hardware channel. HTB derives the channel from TC_H_MIN(opt->classid), and ETS is always attached as a child of an HTB leaf, so its opt->parent matches that classid. Using opt->handle instead can cause two ETS qdiscs on different HTB leaves to collide on the same hardware channel, corrupting scheduler configuration and stats. Fixes: 20bf7d07c956 ("net: airoha: Add sched ETS offload support") Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260720-airoha-ets-handle-fix-v2-1-6f7129ddc06f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23ASoC: meson: preparation for Card capsulingMark Brown3-20/+33
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> says: These are v2 patch-set of meson preparation for Card capsuling. I will post Card capsuling patch. To makes its review easy, tidyup meson drivers to reduce un-related diff as preparation. No functional change, but is preparation for cleanup driver. Link: https://patch.msgid.link/87bjbytkej.wl-kuninori.morimoto.gx@renesas.com
2026-07-23ASoC: meson: meson-card-utils: tidyup not to use card->devKuninori Morimoto1-8/+14
struct snd_soc_card will be capsuled soon, its member will not be able to access from non soc-card.c. To reduce the difference during conversion, replace dev. - card->dev, ... + dev, ... No functional change, but is preparation for Card capsuling. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://patch.msgid.link/877bmmtkds.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-23ASoC: meson: gx-card: tidyup not to use card->devKuninori Morimoto1-2/+4
struct snd_soc_card will be capsuled soon, its member will not be able to access from non soc-card.c. To reduce the difference during conversion, replace dev. - card->dev, ... + dev, ... No functional change, but is preparation for Card capsuling. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://patch.msgid.link/878q72tkdw.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit (git 2.54.0.dirty) at 2026-09-30 19:26:24 +0000