summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-08-04mm/damon/core: stop ctxs in damon_start() before returning an errorSJ Park
Patch series "mm/damon: refactor damon_{start,stop,commit}() for simple error handling". damon_start() and damon_stop() could leave a few of requested DAMON contexts running when they return an error. damon_commit() failure stops the DAMON context, but in an asynchronous way. Callers should stop the left-over DAMON contexts. It is easy to make mistakes, and indeed a few bugs from such mistakes were found and fixed. Refactor the core API functions to guarantee contexts are completely stopped under failures. Remove the caller side error handlers that are no longer needed due to the refactoring. Patches Sequence ================ Patch 1 refactors damon_start() to ensure all contexts are stopped for failures. Patch 2 updates unnecessary damon_start() error handling from mtier sample module. Patch 3 refactors damon_stop() to always success. Patches 4-6 updates callers (damon_{sysfs,reclaim lru_sort}) to ignore the return value. Patch 7 update damon_stop() return value to void. Patch 8 simplifies damon_stop() error handling in mtier sample module. Patch 9 refactors damon_call() to return errors only after the context is completely stopped. Patches 10 and 11 remove unnecessary error handlings from callers (wsse and prcl sample modules). This patch (of 11): When multiple contexts are passed to damon_start(), the function starts the contexts one by one. If any of the operations fails, it immediately returns an error. Contexts that successfully started before the failure keep running. The caller should catch this and stop the contexts. It is complicated and easy to make mistakes. Stop all contexts in damon_start() under the failures. Link: https://lore.kernel.org/20260706140628.87414-1-sj@kernel.org Link: https://lore.kernel.org/20260706140628.87414-2-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-04selftests/damon: check correct path in ensure_file() not_exist casewang wei
In the ensure_file() function, the "not_exist" code path checks whether $dir exists as a regular file. However, the intent is to verify that the target file ($file) does not exist, not the $dir. Testing $dir makes the existence check effectively useless -- it tests the wrong path and thus never catches the case where the file is unexpectedly present. Replace $dir with $file so the not_exist verification targets the correct path. Link: https://lore.kernel.org/20260706134305.5224-1-a929244872@163.com Signed-off-by: wang wei <a929244872@163.com> Reviewed-by: SJ Park <sj@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-04lib/maple_tree: add missing spaces after switch keywordWatson Wheeler
Add the required space before the opening parenthesis in switch statements to conform to kernel coding style. Link: https://lore.kernel.org/20260623061730.2024-1-git@tazy.dev Signed-off-by: Watson Wheeler <git@tazy.dev> Reviewed-by: Liam Howlett <liam@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-04percpu: replace __ASSEMBLY__ with __ASSEMBLER__ in percpu-defs.h header fileThomas Huth
While the GCC and Clang compilers already define __ASSEMBLER__ automatically when compiling assembly code, __ASSEMBLY__ is a macro that only gets defined by the Makefiles in the kernel. This can be very confusing when switching between userspace and kernelspace coding, or when dealing with uapi headers that rather should use __ASSEMBLER__ instead. So let's standardize now on the __ASSEMBLER__ macro that is provided by the compilers. This is a completely mechanical patch (done with a simple "sed -i" statement. Link: https://lore.kernel.org/20260619154704.41293-1-thuth@redhat.com Signed-off-by: Thomas Huth <thuth@redhat.com> Cc: Dennis Zhou <dennis@kernel.org> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-04Documentation: document panic_on_unrecoverable_memory_failure sysctlBreno Leitao
Add documentation for the new vm.panic_on_unrecoverable_memory_failure sysctl, describing which failures trigger a panic (kernel-owned pages the handler cannot recover) and which are intentionally left out (transient allocator races and unclassified pages). Link: https://lore.kernel.org/20260630-ecc_panic-v10-5-c6ed5b62eea2@debian.org Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Miaohe Lin <linmiaohe@huawei.com> Cc: David Hildenbrand (Arm) <david@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-04mm/memory-failure: add panic option for unrecoverable pagesBreno Leitao
Add a sysctl panic_on_unrecoverable_memory_failure (disabled by default) that triggers a kernel panic when memory_failure() encounters pages that cannot be recovered. This provides a clean crash with useful debug information rather than allowing silent data corruption or a delayed crash at an unrelated code path. Panic eligibility is intentionally narrow: only MF_MSG_KERNEL with result == MF_IGNORED panics. After the previous patch, MF_MSG_KERNEL covers PG_reserved pages and the kernel-owned pages promoted from get_hwpoison_page() via -ENOTRECOVERABLE (slab, page tables, large-kmalloc). All other action types are excluded: - MF_MSG_GET_HWPOISON and MF_MSG_KERNEL_HIGH_ORDER can be reached by transient refcount races with the page allocator (an in-flight buddy allocation has refcount 0 and is no longer on the buddy free list, briefly), and panicking on them would risk killing the box for what is actually a recoverable userspace page. - MF_MSG_UNKNOWN means identify_page_state() could not classify the page; that is precisely the wrong basis for a panic decision. Link: https://lore.kernel.org/20260630-ecc_panic-v10-4-c6ed5b62eea2@debian.org Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Miaohe Lin <linmiaohe@huawei.com> Cc: David Hildenbrand (Arm) <david@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-04mm/memory-failure: report MF_MSG_KERNEL for unrecoverable kernel pagesBreno Leitao
The previous patch teaches get_any_page() to return -ENOTRECOVERABLE for stable unhandlable kernel pages (PG_reserved, slab, page tables, large-kmalloc). memory_failure() still folds every negative return into MF_MSG_GET_HWPOISON, so callers that want to react to the unrecoverable cases (a panic option, smarter logging) cannot tell them apart from transient page-allocator races. Turn the post-call branch into a switch over the get_hwpoison_page() return code: map -ENOTRECOVERABLE to MF_MSG_KERNEL and any other negative return to MF_MSG_GET_HWPOISON. case 0 keeps the existing free-buddy / kernel-high-order handling and case 1 falls through to the rest of memory_failure() unchanged. The MF_MSG_KERNEL label and tracepoint string are kept as "reserved kernel page" to avoid breaking userspace tools that match on those literals; the enum value still adequately tags the failure even though it now also covers slab, page tables and large-kmalloc pages. Link: https://lore.kernel.org/20260630-ecc_panic-v10-3-c6ed5b62eea2@debian.org Signed-off-by: Breno Leitao <leitao@debian.org> Suggested-by: David Hildenbrand <david@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Acked-by: Miaohe Lin <linmiaohe@huawei.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-04mm/memory-failure: surface unhandlable kernel pages as -ENOTRECOVERABLEBreno Leitao
get_any_page() collapses every HWPoisonHandlable() rejection into a single -EIO via the __get_hwpoison_page() -> -EBUSY -> shake_page() -> retry path. That is correct for the transient case (a userspace folio briefly off LRU during migration or compaction, which a later shake can drag back), but wrong for stable kernel-owned pages: slab, page-table, large-kmalloc and PG_reserved pages will never become HWPoisonHandlable(), so the retry loop is wasted work and the final -EIO loses the "this is structurally unrecoverable" information. memory_failure() then maps -EIO into MF_MSG_GET_HWPOISON, which the panic-on-unrecoverable sysctl deliberately does not act on. Introduce is_kernel_owned_page(), a small predicate that positively identifies pages the hwpoison handler cannot recover from: is_kernel_owned_page(p) := PageReserved(p) || PageSlab(head) || PageTable(head) || PageLargeKmalloc(head) where head = compound_head(p). PG_reserved is a per-page flag (PF_NO_COMPOUND) and is tested on the page directly. The slab, page-table and large-kmalloc page-type bits are only stored on the head page, so those tests resolve the compound head first, then re-read compound_head(page) afterwards: a concurrent split or compound free that moves head invalidates the just-read flags and the loop retries. The lookup still takes no refcount, mirroring the rest of get_any_page(); the recheck closes the common split race, and a residual free->alloc->free in the same window can only mis-tag a genuinely poisoned page, never reclassify a handlable one. No MF_SOFT_OFFLINE / page_has_movable_ops() opt-out is needed: a movable_ops page is always PageOffline or PageZsmalloc, whose page_type is mutually exclusive with slab, page-table and large-kmalloc, and it never carries PG_reserved, so it can never match any of the checks above. The list is intentionally not exhaustive. vmalloc and kernel-stack pages, for example, do not carry a page_type bit and would need a different oracle; they keep going through the existing retry path unchanged. This is the smallest set we can identify with certainty by page type. Wire the helper into the top of get_any_page() to short-circuit those pages before the retry loop runs. On a hit, drop the caller's MF_COUNT_INCREASED reference (if any) and return -ENOTRECOVERABLE straight away. Pages outside the helper's positive list still take the existing retry path and return -EIO, leaving operator-visible behaviour for those cases unchanged. Extend the unhandlable-page pr_err() to fire for either errno and update the get_hwpoison_page() kerneldoc to document the new return. memory_failure() still folds every negative return into MF_MSG_GET_HWPOISON via its existing "else if (res < 0)" branch, so this patch on its own only changes the errno that soft_offline_page() can propagate to its callers. A follow-up wires -ENOTRECOVERABLE through memory_failure() and reports MF_MSG_KERNEL for the unrecoverable cases, which is what the panic_on_unrecoverable_memory_failure sysctl observes. Link: https://lore.kernel.org/20260630-ecc_panic-v10-2-c6ed5b62eea2@debian.org Signed-off-by: Breno Leitao <leitao@debian.org> Suggested-by: David Hildenbrand <david@kernel.org> Suggested-by: Lance Yang <lance.yang@linux.dev> Acked-by: Miaohe Lin <linmiaohe@huawei.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-04mm/memory-failure: drop dead error_states[] entry for reserved pagesBreno Leitao
Patch series "mm/memory-failure: add panic option for unrecoverable pages", v10. A multi-bit ECC error on a kernel-owned page that the memory failure handler cannot recover is currently swallowed: PG_hwpoison is set, the event is logged, and the kernel keeps running. The corrupted memory remains accessible to the kernel and either drives silent data corruption or surfaces seconds-to-minutes later as an apparently unrelated crash. In a large fleet that delayed, unattributable crash turns into significant engineering effort to root-cause; in a kdump configuration, by the time the crash happens the original error context (faulting PFN, MCE/GHES record, page state) is long gone. This series adds an opt-in sysctl, vm.panic_on_unrecoverable_memory_failure, that converts an unrecoverable kernel-page hwpoison event into an immediate panic with a clean dmesg/vmcore that still contains the original failure context. The default is disabled so existing workloads see no change. There is a selftest that test different cases, and I tested it using the following variants: ┌─────────┬──────────┬───────────────────────────────────────────────────────────┐ │ Variant │ PFN │ Result │ ├─────────┼──────────┼───────────────────────────────────────────────────────────┤ │ rodata │ 0x2600 │ Panic with "Memory failure: 0x2600: unrecoverable page" │ ├─────────┼──────────┼───────────────────────────────────────────────────────────┤ │ slab │ 0x100032 │ Panic with "Memory failure: 0x100032: unrecoverable page" │ ├─────────┼──────────┼───────────────────────────────────────────────────────────┤ │ pgtable │ 0x100000 │ Panic with "Memory failure: 0x100000: unrecoverable page" │ └─────────┴──────────┴───────────────────────────────────────────────────────────┘ Each one shows the same call trace, exactly the path the series builds: hard_offline_page_store → memory_failure → action_result → panic("Memory failure: %#lx: unrecoverable page") This patch (of 5): The first entry of error_states[], { reserved, reserved, MF_MSG_KERNEL, me_kernel }, is unreachable. identify_page_state() has two callers, and neither one can dispatch a PG_reserved page to me_kernel(): * memory_failure() reaches identify_page_state() only after get_hwpoison_page() returned 1. get_any_page() reaches that return only via __get_hwpoison_page(), which only takes a refcount when the page is HWPoisonHandlable(). HWPoisonHandlable() is an allowlist for LRU, free-buddy, and (for soft-offline) movable_ops pages -- PG_reserved pages do not satisfy any of these, so they fail with -EBUSY/-EIO long before identify_page_state() runs. * try_memory_failure_hugetlb() reaches identify_page_state() only via the MF_HUGETLB_IN_USED branch, where the page is necessarily a hugetlb folio. hugetlb folios don't carry PG_reserved at that point: hugetlb_folio_init_vmemmap() calls __folio_clear_reserved() during init, so the reserved entry would not match even if it were still present. me_kernel() never executes and the entry exists only to be matched against by code that cannot see it. Drop the entry, the me_kernel() helper, and the now-unused "reserved" macro. Leave the MF_MSG_KERNEL enum value in place: it remains part of the tracepoint and pr_err() string tables, and follow-on work to classify unrecoverable kernel pages can reuse it without churning the user-visible enum. No functional change. Link: https://lore.kernel.org/20260630-ecc_panic-v10-0-c6ed5b62eea2@debian.org Link: https://lore.kernel.org/20260630-ecc_panic-v10-1-c6ed5b62eea2@debian.org Signed-off-by: Breno Leitao <leitao@debian.org> Suggested-by: David Hildenbrand <david@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Lance Yang <lance.yang@linux.dev> Acked-by: Miaohe Lin <linmiaohe@huawei.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-04memcg-v1: bail out reclaim when memcg is dyingJiayuan Chen
The legacy memory.limit_in_bytes and memory.memsw.limit_in_bytes writers retry page_counter_set_max() by reclaiming synchronously in the writer context. memory.force_empty similarly loops in synchronous reclaim until the cgroup is empty or reclaim stops making progress. These writes hold a kernfs active reference on the file. If cgroup removal starts in parallel, the remover sets CSS_DYING and then waits in kernfs_drain() under cgroup_mutex for the active reference to drain. Continuing reclaim after the memcg is dying can therefore delay cgroup removal and keep cgroup_mutex held for a long time. Stop the v1 reclaim loops once the memcg is dying. For limit resizing, keep the existing -EBUSY semantics when the new limit could not be installed. For memory.force_empty, keep the existing best-effort success semantics. Link: https://lore.kernel.org/20260702120235.376752-5-jiayuan.chen@linux.dev Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com> Reported-by: Zhou Yingfu <yingfu.zhou@shopee.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Jiayuan Chen <jiayuan.chen@linux.dev> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: Barry Song <baohua@kernel.org> Cc: David Hildenbrand <david@kernel.org> Cc: Kairui Song <kasong@tencent.com> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Wei Xu <weixugc@google.com> Cc: Yuanchu Xie <yuanchu@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-04memcg: bail out proactive reclaim when memcg is dyingJiayuan Chen
Proactive reclaim via memory.reclaim can run for a long time - swap I/O or thrashing again dominating the latency - and delays cgroup removal in the same way. Mitigate this by stopping the reclaim once memcg_is_dying(). Link: https://lore.kernel.org/20260702120235.376752-4-jiayuan.chen@linux.dev Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com> Reported-by: Zhou Yingfu <yingfu.zhou@shopee.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Jiayuan Chen <jiayuan.chen@linux.dev> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: Barry Song <baohua@kernel.org> Cc: David Hildenbrand <david@kernel.org> Cc: Kairui Song <kasong@tencent.com> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Wei Xu <weixugc@google.com> Cc: Yuanchu Xie <yuanchu@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-04memcg: bail out memory.max when memcg is dyingJiayuan Chen
memory.max has the same high-latency reclaim loop as memory.high, and may additionally invoke the OOM killer on a cgroup that is already going away, further delaying its removal. Mitigate this by bailing out of the loop once memcg_is_dying(). Link: https://lore.kernel.org/20260702120235.376752-3-jiayuan.chen@linux.dev Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com> Reported-by: Zhou Yingfu <yingfu.zhou@shopee.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Jiayuan Chen <jiayuan.chen@linux.dev> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: Barry Song <baohua@kernel.org> Cc: David Hildenbrand <david@kernel.org> Cc: Kairui Song <kasong@tencent.com> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Wei Xu <weixugc@google.com> Cc: Yuanchu Xie <yuanchu@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-04memcg: bail out memory.high when memcg is dyingJiayuan Chen
Patch series "memcg: bail out reclaim when memcg is dying", v3. This series mitigates a system-wide stall we hit when a cgroup is removed while one of its memory control files is doing synchronous reclaim. Problem Description =================== Writing to memory.high, memory.max or memory.reclaim runs reclaim synchronously in the writer's context, looping until the usage drops below the target (or, for memory.reclaim, until the requested amount has been reclaimed). On a large cgroup this can take a long time. The latency is especially bad when reclaim has to perform swap I/O, where it is bound by the swap device write bandwidth, and under thrashing it is effectively unbounded - each round reclaims a few pages that the workload immediately faults back in, so the loop keeps making "progress" and never converges. The legacy (v1) reclaim loops in memory.limit_in_bytes, memory.memsw.limit_in_bytes and memory.force_empty share the same pattern. These writes go through cgroup_file_write(), which does not take cgroup_mutex and does not pin the css. Instead, kernfs guarantees the node (and thus the css) stays alive for the duration of the operation by holding an active reference. So while the reclaim loop runs, the active reference on the file is held. If another task removes the same cgroup in parallel, cgroup_rmdir() takes cgroup_mutex and then blocks in kernfs_drain() waiting for that active reference to drain. Because cgroup_mutex is held throughout the wait, every other task that needs it piles up behind the remover - in our case the whole machine ground to a halt, with hung_task reports for the remover and for unrelated tasks merely reading /proc/<pid>/cgroup: INFO: task cgdelete:366634 blocked for more than 159 seconds. Not tainted 6.6.102+ #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Call Trace: <TASK> __schedule+0x3da/0x1650 schedule+0x58/0x100 kernfs_drain+0xe6/0x150 __kernfs_remove.part.0+0xd0/0x200 kernfs_remove_by_name_ns+0x75/0xd0 cgroup_addrm_files+0x325/0x410 css_clear_dir+0x50/0xf0 cgroup_destroy_locked+0xdf/0x1e0 cgroup_rmdir+0x2d/0xd0 kernfs_iop_rmdir+0x53/0x90 vfs_rmdir+0x98/0x240 do_rmdir+0x172/0x1b0 __x64_sys_rmdir+0x42/0x70 x64_sys_call+0xeb0/0x2210 do_syscall_64+0x56/0x90 entry_SYSCALL_64_after_hwframe+0x78/0xe2 INFO: task systemd-journal:2352 blocked for more than 182 seconds. Not tainted 6.6.102+ #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Call Trace: <TASK> __schedule+0x3da/0x1650 schedule+0x58/0x100 schedule_preempt_disabled+0xe/0x20 __mutex_lock.constprop.0+0x3bb/0x640 __mutex_lock_slowpath+0x13/0x20 mutex_lock+0x3c/0x50 proc_cgroup_show+0x4d/0x380 proc_single_show+0x53/0xe0 seq_read_iter+0x12f/0x4b0 seq_read+0xcd/0x110 vfs_read+0xb1/0x360 ? __seccomp_filter+0x368/0x590 ksys_read+0x73/0x100 __x64_sys_read+0x19/0x30 x64_sys_call+0x18d3/0x2210 do_syscall_64+0x56/0x90 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The system recovers only once the reclaim finally finishes and releases the active reference. The reclaim itself is pointless here: the cgroup is being torn down and its remaining pages will be reparented to the parent anyway. Even though we check signal_pending(current) in the reclaim loop, the typical symptom is that cat /proc/<pid>/cgroup gets stuck. By the time someone looks for which task is actually stuck in reclaim, the hung task timeout has already been hit. This makes the problem particularly nasty to debug from a hung-task report alone, because the blocked tasks shown are often the victims, not the reclaim writer itself. Our Mitigation ============== cgroup destruction sets CSS_DYING in kill_css_sync() *before* css_clear_dir() triggers the kernfs_drain() that blocks the remover. The in-flight reclaim loop is therefore guaranteed to observe it before starting another reclaim iteration. This series checks memcg_is_dying() in the v2 reclaim loops (memory.high, memory.max and proactive reclaim) and the v1 reclaim loops (memory.limit_in_bytes, memory.memsw.limit_in_bytes and memory.force_empty), and bails out early, so the writer drops the active reference promptly and the remover can make progress. Unlike the no-progress guard (MAX_RECLAIM_RETRIES), which only fires when reclaim makes zero progress, the dying check also covers the slow swap I/O and thrashing cases, where reclaim keeps succeeding a little and the loop would otherwise never converge. For memory.reclaim, bailing out because the memcg is dying means the requested reclaim amount was not satisfied, so the write returns -EAGAIN. This is orthogonal to commit c8e6002bd611 ("memcg: introduce non-blocking limit setting option"): O_NONBLOCK lets a caller avoid the synchronous reclaim up front, while this series handles the case where reclaim is already running when the cgroup starts being removed. This patch (of 4): memory.high reclaims synchronously in the writer's context, and the latency can be very high - especially when reclaim performs swap I/O, or under thrashing where the loop may not converge for a long time. While this runs the kernfs active reference on the file is held, so a concurrent removal of the same cgroup blocks in kernfs_drain() under cgroup_mutex until it finishes. Reclaiming a dying cgroup is pointless, as its pages are reparented to the parent anyway. Mitigate this by bailing out of the reclaim loop once memcg_is_dying(). Link: https://lore.kernel.org/20260702120235.376752-1-jiayuan.chen@linux.dev Link: https://lore.kernel.org/20260702120235.376752-2-jiayuan.chen@linux.dev Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com> Reported-by: Zhou Yingfu <yingfu.zhou@shopee.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: Barry Song <baohua@kernel.org> Cc: David Hildenbrand <david@kernel.org> Cc: Kairui Song <kasong@tencent.com> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Wei Xu <weixugc@google.com> Cc: Yuanchu Xie <yuanchu@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-04Merge branch 'mm-hotfixes-stable' into mm-stable in order to pick upAndrew Morton
vmscan.c changes which are required by "memcg: bail out proactive reclaim when memcg is dying".
2026-08-04net/mlx5e: fix BQL reset on SQ re-activationBobby Eshleman
mlx5e_queue_start() deactivates and re-activates all channels but closes only the queue being restarted. mlx5e_activate_txqsq() then unconditionally calls netdev_tx_reset_queue(), zeroing the BQL counters of channels that kept their in-flight TX WQEs. The next completion then over-charges and trips the BUG_ON() in dql_completed(): kernel BUG at lib/dynamic_queue_limits.c:99! RIP: 0010:dql_completed+0x23d/0x280 Call Trace: <IRQ> mlx5e_poll_tx_cq+0x668/0xa60 mlx5e_napi_poll+0x5b/0x7b0 net_rx_action+0x15a/0x580 Reset BQL only when the SQ has no bytes in flight (sq->cc == sq->pc). In the case that reset is skipped, the outstanding WQEs will eventually complete and rebalance the dql. The dql->limit is carried across the reset. Fixes: b2588ea40ec9 ("net/mlx5e: Implement queue mgmt ops and single channel swap") Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260803-mlx5-bql-v3-1-a30d4c66fe1d@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04net: bonding: check register_netdevice_notifier() error in bonding_init()Minhong He
bonding_init() ignores register_netdevice_notifier() errors and still returns success, which can leave the bonding module loaded without its netdev notifier registered. Check the error and unwind prior initialization on failure. This is a future looking check, register_netdevice_notifier() only fails on double registration or if the registered notifier itself returns an error. Signed-off-by: Minhong He <heminhong@kylinos.cn> Acked-by: Jay Vosburgh <jv@jvosburgh.net> Link: https://patch.msgid.link/20260803090012.142638-1-heminhong@kylinos.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04net: vrf: check register_netdevice_notifier() error in vrf_init_module()Minhong He
vrf_init_module() ignores register_netdevice_notifier() errors and continues module initialization, which can leave VRF loaded without its netdev notifier registered. Check the error and fail module initialization early. This is a future looking check, register_netdevice_notifier() only fails on double registration or if the registered notifier itself returns an error. Signed-off-by: Minhong He <heminhong@kylinos.cn> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20260803090002.142453-1-heminhong@kylinos.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04net: macvlan: check register_netdevice_notifier() error in macvlan_init_module()Minhong He
macvlan_init_module() ignores register_netdevice_notifier() errors and continues module initialization, which can leave macvlan loaded without its netdev notifier registered. Check the error and fail module initialization early. This is a future looking check, register_netdevice_notifier() only fails on double registration or if the registered notifier itself returns an error. Signed-off-by: Minhong He <heminhong@kylinos.cn> Link: https://patch.msgid.link/20260803085950.142325-1-heminhong@kylinos.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04net: team: check register_netdevice_notifier() error in team_module_init()Minhong He
team_module_init() ignores register_netdevice_notifier() errors and continues module initialization, which can leave the team module loaded without its netdev notifier registered. Check the error and fail module initialization early. This is a future looking check, register_netdevice_notifier() only fails on double registration or if the registered notifier itself returns an error. Signed-off-by: Minhong He <heminhong@kylinos.cn> Link: https://patch.msgid.link/20260803085943.142261-1-heminhong@kylinos.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04net: lapbether: check register_netdevice_notifier() error in ↵Minhong He
lapbeth_init_driver() lapbeth_init_driver() ignores register_netdevice_notifier() errors and always returns success, which can leave the module loaded without its netdev notifier registered. Check the error and remove the packet type on failure. This is a future looking check, register_netdevice_notifier() only fails on double registration or if the registered notifier itself returns an error. Signed-off-by: Minhong He <heminhong@kylinos.cn> Link: https://patch.msgid.link/20260803085936.142160-1-heminhong@kylinos.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04net: failover: check register_netdevice_notifier() error in failover_init()Minhong He
failover_init() ignores register_netdevice_notifier() errors and always returns success, which can leave the failover module loaded without its netdev notifier registered. Return the notifier registration result directly so module initialization fails when registration fails. This is a future looking check, register_netdevice_notifier() only fails on double registration or if the registered notifier itself returns an error. Signed-off-by: Minhong He <heminhong@kylinos.cn> Link: https://patch.msgid.link/20260731030338.82508-1-heminhong@kylinos.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04ipv4: nexthop: handle errors in nexthop_init()Minhong He
nexthop_init() ignores errors from register_pernet_subsys() and register_netdevice_notifier(), so a partial initialization can appear successful. Check those steps and unwind prior registrations on failure. Do not check rtnl_register_many(): for built-in code it panics on failure, so the call cannot return an error to nexthop_init(). Cc: stable+noautosel@kernel.org # untested fix to unlikely error path Signed-off-by: Minhong He <heminhong@kylinos.cn> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260731025249.80026-1-heminhong@kylinos.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05f2fs: fix valid block count leak on data block allocation failureChen Changcheng
In __allocate_data_block(), when allocating a new data block (dn->data_blkaddr == NULL_ADDR), inc_valid_block_count() is called first to increment total_valid_block_count and i_blocks. If the subsequent f2fs_allocate_data_block() fails, the function returns the error directly without rolling back the already-incremented block counts, causing a permanent leak. Fix this by calling dec_valid_block_count() to undo the increment before returning the error. The condition old_blkaddr == NULL_ADDR precisely identifies the case where inc_valid_block_count() was called. Fixes: 7d009e048d7c ("f2fs: fix to handle segment allocation failure correctly") Cc: <stable@vger.kernel.org> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Chen Changcheng <chenchangcheng@kylinos.cn> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-08-05f2fs: protect critical_task_priority updates with s_umountWenjie Qi
The sysfs store path already takes s_umount for GC thread control entries, and ckpt_thread_ioprio is covered as well. critical_task_priority also updates checkpoint or GC kthread scheduling state, but it is not covered by that serialization. It can race with remount or teardown paths that are stopping those threads. Protect critical_task_priority sysfs writes with s_umount too. Fixes: 52190933c37a ("f2fs: sysfs: introduce critical_task_priority") 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-05f2fs: avoid NULL checkpoint thread access in sysfsWenjie Qi
checkpoint_merge can be enabled even when no checkpoint merge thread is running. A read-only mount is one case: f2fs does not start f2fs_issue_ckpt there, but ckpt_thread_ioprio is still writable through sysfs. The ckpt_thread_ioprio store path updates the saved ioprio value and, when checkpoint_merge is enabled, calls set_task_ioprio() for the checkpoint thread. If cprc->f2fs_issue_ckpt is NULL, that dereferences a NULL task pointer. Protect ckpt_thread_ioprio sysfs writes with s_umount as well, so the checkpoint thread cannot disappear under the store path while updating its ioprio. Fixes: e65920661708 ("f2fs: add ckpt_thread_ioprio sysfs node") 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-04net: openvswitch: reallocate update replies for mismatched IDsZhiling Zou
ovs_flow_cmd_new() preallocates the optional reply skb before it takes ovs_mutex and before it knows which existing flow will be updated. That is normally fine because the skb is sized from the request flow identifier. That identifier also becomes the inserted flow's identifier. For updates, however, a request with a UFID may miss the UFID lookup and then fall back to the flow key lookup. That lookup can legitimately find an existing key-identified flow. UFIDs are optional and the flow key is the primary identifier. For echoed replies, ovs_flow_cmd_fill_info() writes the matched flow's identifier, not the request identifier used for the preallocation. A short request UFID can therefore leave too little room for the key identifier. The fill can then fail with -EMSGSIZE and hit the BUG_ON(error < 0) in the update path. Once the update target has been resolved, reallocate the reply skb if the matched flow needs a larger reply than the request identifier allowed. Do this before replacing the actions so the request can still fail cleanly if the rare extra allocation fails. Fixes: 74ed7ab9264c ("openvswitch: Add support for unique flow IDs.") Cc: stable@vger.kernel.org Reported-by: Vega <vega@nebusec.ai> Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai> Reviewed-by: Ilya Maximets <i.maximets@ovn.org> Link: https://patch.msgid.link/f7bbd3c30ce81a39156e226b3872d73abed21d2f.1785644623.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04usbnet: cap max_mtu for drivers without bind callbackLaurent Vivier
usbnet_probe() initializes max_mtu to ETH_MAX_MTU and only caps it inside the if (info->bind) block. Drivers without a bind callback never enter this block, so max_mtu stays at ETH_MAX_MTU. QEMU's usb-net device (0x0525/0xa4a2) is claimed by the cdc_subset driver which has no bind callback. The guest accepts any MTU from DHCP (e.g. 65520 from passt), leading to TCP segments that exceed the device's 2048-byte receive buffer and are silently dropped. Initialize max_mtu to net->mtu at probe time and update it inside the bind block. Fixes: f77f0aee4da4 ("net: use core MTU range checking in USB NIC drivers") Cc: jarod@redhat.com Cc: stable@vger.kernel.org Link: https://gitlab.com/qemu-project/qemu/-/issues/3268 Link: https://bugs.passt.top/show_bug.cgi?id=189 Signed-off-by: Laurent Vivier <lvivier@redhat.com> Link: https://patch.msgid.link/20260731092711.857684-1-lvivier@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04bnge: use int for bnge_fix_rings_count() return valueAlok Tiwari
bnge_fix_rings_count() returns 0 on success or a negative errno on failure However, bnge_adjust_rings() stores its return value in a u16 variable, causing negative error codes such as -ENOMEM to be converted to a large positive value. Use an int for the return code variable so that error values are preserved and propagated correctly. Fixes: 627c67f038d2 ("bng_en: Add resource management support") Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Bhargava Marreddy <bhargava.marreddy@broadcom.com> Link: https://patch.msgid.link/20260801100923.1498570-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04Merge branch 'net-atlantic-fix-two-ring-teardown-leaks'Jakub Kicinski
Yangyu Chen says: ==================== net: atlantic: fix two ring teardown leaks These are the two fixes from the page_pool conversion series [1], resent against net as requested in the review of that series. The page_pool conversion itself stays in net-next and is not part of this posting; it depends on these fixes, but they stand on their own. Both patches are unchanged from [1] apart from the collected Reviewed-by tags, and each carries a Fixes tag and a Cc: stable with the affected range (patch 1: v4.11+, patch 2: v5.2+). They apply and were build- and runtime-tested independently of each other and of the conversion. Patch 1: aq_vec_deinit() drains the TX rings with a single aq_ring_tx_clean() call, which is capped at AQ_CFG_TX_CLEAN_BUDGET descriptors and stops at hw_head, frozen once the hardware and NAPI have been stopped. Everything beyond that keeps its skb or xdp_frame when the interface goes down and is lost when the buffer ring is freed. Patch 2: aq_ring_rx_deinit() only walks [sw_head, sw_tail). Since the page reuse strategy was added, a cleaned RX buffer keeps its page for reuse and refill is batched, so consumed but not yet reposted slots accumulate in the [sw_tail, sw_head) gap and their pages and DMA mappings are never released. Reproduction logs for both leaks (as page_pool stalled shutdowns, which is how they become visible) are in the notes of the respective patches. [1] https://lore.kernel.org/lkml/tencent_1F173E0FC1606D2AC704DC9C98AF10984607@qq.com/ ==================== Link: https://patch.msgid.link/tencent_29B860317921D68DE77C718242DA418EB608@qq.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04net: atlantic: free RX pages of consumed but not refilled buffersYangyu Chen
aq_ring_rx_deinit() only walks [sw_head, sw_tail), the region posted to hardware. Since the page reuse strategy was added, a cleaned RX buffer keeps its page (and its DMA mapping) in the ring for reuse, and refill is batched: aq_ring_rx_fill() returns early until AQ_CFG_RX_REFILL_THRES slots are free. Slots that were consumed but not yet reposted therefore sit in the complementary [sw_tail, sw_head) gap with a live page, and the deinit walk never visits them: up to a refill batch worth of pages and DMA mappings leak on every interface down. Walk the whole ring instead and release whatever is still there. Also bail out if the buffer ring is already gone: a partial aq_ptp_ring_alloc() failure frees the ring but leaves aq_nic set, so aq_ptp_ring_deinit() still gets here on the unwind path. Cc: stable@vger.kernel.org # v5.2+ Fixes: 46f4c29d9de6 ("net: aquantia: optimize rx performance by page reuse strategy") Reviewed-by: Sukhdeep Singh <sukhdeeps@marvell.com> Signed-off-by: Yangyu Chen <cyy@cyyself.name> Acked-by: Mina Almasry <almasrymina@google.com> Link: https://patch.msgid.link/tencent_607CBA8237DA438E36B844318B21538DE008@qq.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04net: atlantic: free stranded TX buffers on ring deinitYangyu Chen
aq_vec_deinit() drains the TX rings with a single aq_ring_tx_clean() call, which frees at most AQ_CFG_TX_CLEAN_BUDGET (256) descriptors and stops at hw_head, which no longer moves once aq_vec_stop() has stopped the hardware and NAPI. Completed descriptors beyond the budget and everything still posted in [hw_head, sw_tail) keep their skb or xdp_frame when the interface goes down: aq_vec_ring_free() then frees the buffer ring and the references are lost for good. Today this is a silent memory leak on every interface down under TX/XDP_TX load. With the conversion of the RX path to page_pool posted for net-next it becomes much more visible: XDP_TX frames carry fragment references on the RX ring's page_pool, so a single stranded frame keeps the pool's inflight count above zero forever. page_pool_destroy() then never completes, the pool is leaked together with its pages, and "page_pool_release_retry() stalled pool shutdown" is warned every 60 seconds from that point on, on every ifdown, XDP detach or ring resize under XDP_TX load. Bring back aq_ring_tx_deinit() as it was before the removal and use it for teardown again, with one extension: TX rings can hold xdp_frames nowadays, so release those too. They are returned with xdp_return_frame() since this runs in process context. Fixes: eb36bedf28be ("net: aquantia: remove function aq_ring_tx_deinit") Cc: stable@vger.kernel.org # v4.11+ Reviewed-by: Sukhdeep Singh <sukhdeeps@marvell.com> Signed-off-by: Yangyu Chen <cyy@cyyself.name> Acked-by: Mina Almasry <almasrymina@google.com> Link: https://patch.msgid.link/tencent_EEDC35FAF2750A3A6A0B39BAE0E2C484860A@qq.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04net: stmmac: resume PHY before hardware setup when opening the interfaceStefan Agner
Since the referenced commit, changing the MTU on a running interface no longer disconnects and reconnects the PHY; __stmmac_release() merely stops phylink, which also suspends the PHY (BMCR power-down) when WoL is not enabled. __stmmac_open() then performs the DMA software reset in stmmac_hw_setup() before phylink_start() resumes the PHY again. IEEE 802.3 22.2.4.1.5 allows a PHY to stop its receive clock while powered down, and stmmac requires a running receive clock for the DMA software reset to complete (the phylink config sets mac_requires_rxc). On such setups, e.g. the RK3566-based Home Assistant Green with an RTL8211F-VD PHY in RGMII mode, any runtime MTU change now times out and leaves the interface dead: rk_gmac-dwmac fe010000.ethernet end0: Failed to reset the dma rk_gmac-dwmac fe010000.ethernet end0: stmmac_hw_setup: DMA engine initialization failed rk_gmac-dwmac fe010000.ethernet end0: __stmmac_open: Hw setup failed rk_gmac-dwmac fe010000.ethernet end0: failed reopening the interface after MTU change In the field this is triggered by NetworkManager applying an MTU while activating the connection, breaking networking entirely. The same regression has also been reported on i.MX8MP and reproduced on SoCFPGA based systems. Resume the PHY in __stmmac_open() before the hardware setup, making it the counterpart of the phylink_stop() in __stmmac_release(), like stmmac_resume() already does for the same reason. phylink_start() also resumes the PHY, but only after stmmac_hw_setup(), and it cannot be moved before the hardware setup since it may bring the link up immediately from a workqueue, racing with the initialization (see the comment in stmmac_resume()). For the regular ndo_open path the PHY has just been attached and is not suspended, in which case phylink_prepare_resume() does nothing. Fixes: db299a0c09e9 ("net: stmmac: move PHY handling out of __stmmac_open()/release()") Link: https://github.com/home-assistant/operating-system/issues/4858 Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Stefan Agner <stefan@agner.ch> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260803095156.132827-1-stefan@agner.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04net: microchip: vcap api: Fix possible memory leak in vcap_decode_rule()Abdun Nihaal
The memory allocated for struct vcap_rule_internal, keyfields and actionfields inside vcap_dup_rule() are not freed in some of the error paths in vcap_decode_rule(). Fix that by calling vcap_free_rule(). Compile tested only. Issue found using a prototype static analysis tool built on top of the LLVM compiler infrastructure. Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path Reviewed-by: Joe Damato <joe@dama.to> Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Link: https://patch.msgid.link/20260801055507.47534-1-nihaal@cse.iitm.ac.in Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04Merge branch 'net-rds-bug-fix-ports'Jakub Kicinski
Allison Henderson says: ==================== net/rds: Bug fix ports This is a small set of net/rds bug fixes and ports from uek to upstream rds. I've been working on extending the rds selftest case, but need to stabilize a few more bugs and the first few fall into net with Fixes tags. I decided to leverage fable for this set and I thought the ports we clean and well explained. This series fixes a sleeping-in-softirq bug in the RDS message free path, a use-after-free of the RDS socket through long-lived MR references, a message leak in the rds_send_xmit() drop path, and - new in v4 - a pinned-page leak in the IB transport's MR teardown. The first three patches are ports of fixes carried in the Oracle UEK kernel, reworked where the UEK approach no longer applies upstream. ==================== Link: https://patch.msgid.link/20260730041629.3512480-1-achender@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04net/rds: unpin MR pages with unpin_user_pages_dirty_lock()Allison Henderson
The pages backing an RDS memory region are pinned in __rds_rdma_map() with rds_pin_pages(), which uses pin_user_pages_fast(): each page's refcount is biased by GUP_PIN_COUNTING_BIAS to account the pin. The scatterlist is then handed to the IB transport, and the transport releases the pages in __rds_ib_teardown_mr() with set_page_dirty(page); put_page(page); put_page() drops a single reference instead of removing the pin bias, so every MR teardown permanently strands the remaining references and the pages are never freed - a userspace-triggerable memory leak of up to RDS_MAX_MSG_SIZE per RDS_GET_MR/RDS_GET_MR_FOR_DEST call. The conversion to the pin API updated the unpin sites in rdma.c but missed this one on the transport side. Release the pages with unpin_user_pages_dirty_lock(), which removes the pin bias and also dirties the page under the folio lock, closing the truncation race that a bare set_page_dirty() leaves open. Dirtying under the folio lock can sleep, which is safe in every path that reaches __rds_ib_teardown_mr(): the registration-reuse path (rds_ib_map_frmr()) runs in syscall context, and the pool flush (rds_ib_unreg_frmr()) runs under pool->flush_lock, a mutex, and already sleeps in rds_ib_post_inv(). The WARN_ON that guarded the old irq-context set_page_dirty() case is dropped along with it. Signed-off-by: Allison Henderson <achender@kernel.org> Link: https://patch.msgid.link/20260730041629.3512480-5-achender@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04net/rds: fix rds_message leak in the rds_send_xmit() drop pathSharath Srinivasan
When rds_send_xmit() picks the next message off cp_send_queue it takes its own reference with rds_message_addref(). If the message then hits the never-retransmit check (RDS_MSG_FLUSH, or an RDMA op that was already retransmitted), it is moved to the local to_be_dropped list and that reference is dropped after the batch. However, if RDS_MSG_ON_CONN has already been cleared, the message is not added to to_be_dropped and the reference taken above is never dropped: cp_xmit_rm has not been set at this point, so the loop simply abandons rm and the rds_message (and everything it pins: pages, MRs, notifiers) leaks after an RDMA error. The only other places that clear RDS_MSG_ON_CONN are rds_send_path_drop_acked() and rds_send_drop_to(), and both can run while rds_send_xmit() has dropped cp_lock between moving the message to cp_retrans and re-taking the lock in the never-retransmit check: rds_send_path_drop_acked() can ack away a message that already sat on cp_retrans - the RDS_MSG_RETRANSMITTED case above - and rds_send_drop_to() runs on socket close. Both unlink the message under cp_lock and put their own reference, leaving the xmit-path reference stranded. Drop the reference directly in that case. This mirrors Oracle UEK commit "net/rds: fix rds_message memleak in rds_send_xmit". Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com> Signed-off-by: Sharath Srinivasan <sharath.srinivasan@oracle.com> [achender: port to net-next; update commit message, checkpatch nits] Signed-off-by: Allison Henderson <achender@kernel.org> Link: https://patch.msgid.link/20260730041629.3512480-4-achender@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04net/rds: hold the socket while an rds_mr references itHåkon Bugge
Each rds_mr stores a bare back pointer to the socket that created it (mr->r_sock) but takes no reference on it. When the mr is destroyed it references the rs. Hence, provisions must be made to avoid the rs being destroyed before all mrs referencing it have been destroyed. The MR itself is refcounted, and in-flight messages legitimately hold MR krefs that can outlive the socket: rds_release() drops the rb-tree references via rds_rdma_drop_keys(), but a send completion arriving afterwards drops the final message reference from the CQ handler and ends up in rds_message_purge() __rds_put_mr_final() rds_destroy_mr() -> takes rs->rs_rdma_lock dereferencing a socket that may already have been freed. Oracle UEK fixed the same use-after-free ("rds: Add proper refcnt when an RDS MR references an RDS Socket") after seeing crashes of the form: PF: supervisor write access in kernel mode _raw_spin_lock_irqsave+0x4a/0x6a __rds_put_mr_final+0x2c/0xe0 [rds] rds_message_purge+0x13c/0x150 [rds] rds_message_put+0x39/0x54 [rds] rds_ib_send_cqe_handler+0x147/0x3dd [rds_rdma] To fix this, take a socket reference when an MR is created and drop it when the final MR kref goes away. The reference cycle is broken by rds_release(), which always runs rds_rdma_drop_keys() on close. So the socket reference held by an MR never prevents release, it only delays sk_free() until the last MR user is done. The hold sits next to kref_init() at both allocation sites - __rds_rdma_map() and the on-demand-paging path in rds_cmsg_rdma_args() - so every MR owns exactly one socket reference from the moment it becomes kref-managed. For that to work on the ODP path, its get_mr() error handling is converted from a bare kfree() to kref_put(..., __rds_put_mr_final), with r_trans_private cleared first since it holds an ERR_PTR there; both sites then tear down through the same path and a future error-path change cannot silently leak or double-drop the reference. Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com> [achender: port to net-next (sock_hold/sock_put in place of the UEK rds_sock_addref/rds_sock_put helpers); also balance the reference on the rds_cmsg_rdma_args() ODP path and unify its error path with __rds_put_mr_final(); update commit message] Signed-off-by: Allison Henderson <achender@kernel.org> Link: https://patch.msgid.link/20260730041629.3512480-3-achender@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04net/rds: don't use unpin_user_pages_dirty_lock() from atomic contextAllison Henderson
rds_rdma_free_op() and rds_atomic_free_op() are reached from the IB send completion path via rds_ib_tasklet_fn_send() rds_ib_send_cqe_handler() rds_message_put() rds_message_purge() rds_rdma_free_op() / rds_atomic_free_op() which runs in tasklet (softirq) context. Both functions unpin the user pages of the op with unpin_user_pages_dirty_lock(), which uses set_page_dirty_lock() and thus may take the folio lock and sleep. Sleeping in softirq context is not allowed and can deadlock or crash. Dirtying the pages with the non-sleeping set_page_dirty() instead would just trade one bug for another, as pointed out during review: the pinned range can be file-backed. rds_pin_pages() pins with FOLL_LONGTERM, which refuses fs-dax but takes the page-cache pages of a MAP_SHARED file mapping just fine, and RDS does not restrict what memory the caller registers as an RDMA destination. For a file-backed page, set_page_dirty() from a tasklet can take non-irq-safe filesystem locks (e.g. mapping->i_private_lock and inode->i_lock in block_dirty_folio()) and deadlock against the task it interrupted. Without the folio lock, it races with truncation clearing folio->mapping, which is the race set_page_dirty_lock() exists to close. The pre-pin_user_pages() version of this code dirtied pages that way from the tasklet, so that bug is older than the sleeping unpin. The page dirtying therefore has to move to process context, not merely avoid the folio lock. When the final rds_message_put() runs in atomic context, rds_rdma_free_op() and rds_atomic_free_op() now leave the op's pages pinned and flag the op. Later, rds_message_put() hands the message to a work item that unpins the flagged ops' pages and frees the message from process context. Here, unpin_user_pages_dirty_lock() is safe outside the atomic context. Everything else keeps running in the caller's context exactly as before: the rest of the purge - the zerocopy completion, the socket put and the MR reference drops - as well as RDMA writes, whose pages the remote side only reads and which unpin without dirtying, everything on rds_tcp, and final puts that already happen in process context (socket close, connection teardown). Deferring only the unpin means the work item touches nothing but the pinned pages and the rds module's own memory: it cannot call back into a transport module, so it changes nothing about the transports' shutdown and unload ordering. rds_exit() drains any pending unpin work via destroy_workqueue(rds_wq) before the module goes away. The Oracle UEK kernel avoids the sleeping unpin by calling set_page_dirty() directly from the tasklet, which is subject to the file-backed page problem above, so this deliberately does not follow UEK here. Signed-off-by: Allison Henderson <achender@kernel.org> Link: https://patch.msgid.link/20260730041629.3512480-2-achender@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04Merge tag 'ovpn-net-20260730' of https://github.com/OpenVPN/ovpn-net-nextJakub Kicinski
Antonio Quartulli says: ==================== Included fixes: * use rcu_dereference_bh() instead of rcu_access_pointer() where the pointer is actually dereferenced * ensure TCP global variables are initialized before they can be accessed via netlink (e.g. when attaching a TCP socket) * actually disable IPv4 redirects on multipeer interfaces (the previous attempt was a no-op and did not survive netns moves) * hash a floated peer by its transport identity only, consistently with the add and lookup paths * zero the sockaddr padding before learning a floated endpoint so it does not leak into the by_transp_addr hash key * ensure the socket is owned by ovpn before dereferencing sk_user_data * rehash a peer in the by_transp_addr table when its remote endpoint is updated via CMD_PEER_SET * avoid re-adding to the hashtables a peer that was concurrently removed (use-after-free) * limit keepalive values to one day to avoid overflowing the delayed-work delay on 32-bit systems * add the missing rtnl_link_ops->get_size callback so link messages account for the nested mode attribute * tag 'ovpn-net-20260730' of https://github.com/OpenVPN/ovpn-net-next: ovpn: fix incorrect use of rcu_access_pointer() ovpn: ensure TCP vars are initialized first ovpn: disable IPv4 redirects on MP interfaces ovpn: hash floated peer by transport identity only ovpn: zero-initialize sockaddr before learning a floated endpoint ovpn: ensure socket is owned by ovpn before deref sk_user_data ovpn: rehash peer in by_transp_addr table on CMD_PEER_SET ovpn: skip rehash for peers already removed from by_id ovpn: limit keepalive values to one day ovpn: add missing rtnl_link_ops->get_size callback ==================== Link: https://patch.msgid.link/20260730094624.4102963-1-antonio@openvpn.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05iio: dac: mcp47a1: add support for new deviceJoshua Crofts
The Microchip MCP47A1 is a 6-bit volatile Digital-to-Analog converter which communicates via I2C. Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com> Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
2026-08-05dt-bindings: iio: dac: add support for mcp47a1Joshua Crofts
The Microchip MCP47A1 is a 6-bit volatile Digital-to-Analog converter which communicates via I2C. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com> Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
2026-08-05selftests/ftrace: refactor eprobes test to fix argument checksMartin Kaiser
The add/remove eprobe test installs an eprobe for the openat syscall and runs ls. It checks the filenames that were opened by ls against a whitelist and a blacklist. Commit 206b25c09080 ("tracing: eprobe: read the complete FILTER_PTR_STRING pointer") fixed access to some string fields in eprobes. This triggers test failures as the blacklist does not allow relative paths for the openat parameters. What makes this test unstable is the fact that the openat calls vary a lot between different systems. Refactor the test to make it more robust. "cd <directory>" will issue a chdir syscall with the target directory as parameter. Set an eprobe on the sys_enter_chdir event and filter for the exact directory name. Allow (fault) as fallback. Link: https://lore.kernel.org/all/20260804194705.760893-1-martin@kaiser.cx/ Fixes: 206b25c09080 ("tracing: eprobe: read the complete FILTER_PTR_STRING pointer") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202607151010.b68428e1-lkp@intel.com Signed-off-by: Martin Kaiser <martin@kaiser.cx> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-08-04net: dsa: realtek: rtl8366rb: Fix up port isolationLinus Walleij
Sashiko reports that we incorrectly disable isolation in the setup loop while what we want to do is to enable it. Enable it by unconditionally setting the enable bit 0 in rtl8366rb_port_set_isolation() so a mask of 0 when passed in will enable isolation and isolate from ALL ports. Fix up the comments so it is clear what is going on, including a missing word in the helper function. Reported-by: Paolo Abeni <pabeni@redhat.com> Closes: https://sashiko.dev/#/patchset/20260630-rtl8366rb-improvements-v2-0-05eb9d6a37f5%40kernel.org Signed-off-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260731-rtl8366rb-fixes-v4-1-fbf0c95b829a@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-04net: airoha: fix ARRAY_SIZE() division by zero on UP buildsLorenzo Bianconi
airoha_alloc_gdm_device() initializes the txq_lock[] array iterating over ARRAY_SIZE(dev->txq_lock). ARRAY_SIZE() expands to sizeof(dev->txq_lock) / sizeof((dev->txq_lock)[0]), but on UP builds (CONFIG_SMP unset, CONFIG_DEBUG_SPINLOCK unset) arch_spinlock_t is an empty struct, so sizeof(spinlock_t) is zero and the expression is a compile-time division by zero (undefined behavior), reported by clang as "division by zero is undefined [-Wdivision-by-zero]". Since the array is statically sized with AIROHA_NUM_NETDEV_TX_RINGS, use the named constant as loop bound instead of ARRAY_SIZE(). Fixes: 78a35725e533 ("net: airoha: defer GDM3/GDM4 WAN mode and GDM2 loopback to QoS offload") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202607311850.6p0ZUVq4-lkp@intel.com/ Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://patch.msgid.link/20260731-airoha-spinlock-array-fix-v1-1-863a7e239a5f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05ASoC: add and use new snd_soc_register_component()Mark Brown
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> says: Current component has component->name. But snd_soc_register_component() user can't setup it, because component itself is alloced in that function. So, to setup it, user need to use snd_soc_component_initialize() / snd_soc_add_component() directly instead of using snd_soc_register_component(). In the same time, Component will be capsuled soon. Let's tidyup around here. All strange code can be gone if we have both below style. Normal case snd_soc_register_component(dev, ...); Want to setup case component = snd_soc_component_alloc(...); snd_soc_component_set_xxx(component, ...); snd_soc_component_set_xxx(component, ...); (A) snd_soc_register_component(component, ...); This patch-set adds new snd_soc_register_component() which allows to use component (A). Link: https://lore.kernel.org/r/87fr29esth.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87v7ayxk3s.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87zf04c1w5.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87qzkxjg53.wl-kuninori.morimoto.gx@renesas.com Link: https://patch.msgid.link/87y0f2rz8l.wl-kuninori.morimoto.gx@renesas.com
2026-08-05ASoC: soc-core: remove dev from soc_component_initialize()Kuninori Morimoto
Component already has component->dev. No longer need to set dev on soc_component_initialize(). Remove it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/87h5lqrz6z.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-05ASoC: soc-core: makes snd_soc_component_initialize() / ↵Kuninori Morimoto
snd_soc_add_component() local No one is calling snd_soc_component_initialize() / snd_soc_add_component() calling from driver. Makes them local functions. It renames - snd_soc_add_component() + snd_soc_component_add() Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/87ik66rz73.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-05ASoC: soc-topology-test: use snd_soc_register_component()Kuninori Morimoto
It is calling snd_soc_component_initialize() / snd_soc_add_component(). We can now use snd_soc_register_component() instead. It is using container_of() to get kunit_soc_component from component, but will not be able to use it when capsuling has done. We can use snd_soc_component_to_priv() instead. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/87jyqmrz76.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-05ASoC: soc-generic-dmaengine-pcm: use snd_soc_register_component()Kuninori Morimoto
it is calling snd_soc_component_initialize() / snd_soc_add_component(). We can now use snd_soc_register_component() instead. It is using container_of() to get dmaengine_pcm from component, but will not be able to use it when capsuling has done. We can now use snd_soc_component_to_priv() instead. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/87ldb2rz79.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-05ASoC: intel: catpt: pcm: use snd_soc_register_component()Kuninori Morimoto
It is calling snd_soc_component_initialize() / snd_soc_add_component(). We can now use snd_soc_register_component() instead. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/87mrvirz7d.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>