summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2026-08-07soc: fsl: fix kernel-doc warnings and typosRandy Dunlap
Correct spelling of "list". Fix a kernel-doc warning by describing the nested structure completely: include/soc/fsl/dpaa2-fd.h:52: warning: Function parameter or member 'simple' not described in 'dpaa2_fd' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Li Yang <leoyang.li@nxp.com> Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-arm-kernel@lists.infradead.org Cc: Frank Li <Frank.Li@nxp.com> Cc: Guanhua Gao <guanhua.gao@nxp.com> Cc: Roy Pledge <Roy.Pledge@nxp.com> Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com> Link: https://lore.kernel.org/r/20260728004924.904210-1-rdunlap@infradead.org Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
2026-08-06Merge tag 'mm-hotfixes-stable-2026-08-06-18-44' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull MM fixes from Andrew Morton: "17 hotfixes. 15 are cc:stable. 16 are for MM. There's a patch series from Lorenzo "mm: fix UAF caused by race between ptdump and vmap pgtable freeing" which addresses a quite old bug in the ptdump code. And another series also from Lorenzo which fixes a four year old bug in the huge_zero_folio handling. A series from SJ fixes a few possible divide-by-zero issues which Sashiko sniffed out. And a series which fixes handling of the commit_inputs parameters. The remainder are singletons, please see their changelogs for details" * tag 'mm-hotfixes-stable-2026-08-06-18-44' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/damon: adjust isolated pages stat for DAMOS_MIGRATE_{HOT,COLD} mm/damon/ops-common: putback folios on invalid migrate nid mm/huge_memory: initialise workingset state before folio split mm/page_table_check: skip special zero mappings mm/damon/lru_sort: skip damon_call() if ctx has not started mm/damon/reclaim: skip damon_call() if ctx has not started mm/damon/lru_sort: error out for >10000 active_mem_bp samples/damon/mtier: error out for zero quota goal target values mailmap: map old addresses to Danila Tikhonov mm/huge_memory: separate out CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic mm/huge_memory: fix huge_zero_pfn race MAINTAINERS: update address for Brendan Jackman mm/filemap: __filemap_add_folio() restore index before retrying microblaze: restore the page alignment of swapper_pg_dir arm64: remove redundant concurrent ptdump UAF mitigation mm/ptdump: always stabilise against page table freeing using init_mm mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF
2026-08-06mm: fold userfaultfd_rwp() to false without CONFIG_ARCH_HAS_PTE_PROTNONEKiryl Shutsemau (Meta)
RWP tracks accesses by installing PAGE_NONE (protnone) PTEs, so its code paths are gated on userfaultfd_rwp(). Without CONFIG_ARCH_HAS_PTE_PROTNONE there is no PAGE_NONE -- <linux/pgtable.h> defines it to a BUILD_BUG() stub, relying on callers folding such paths to dead code via IS_ENABLED(CONFIG_ARCH_HAS_PTE_PROTNONE). userfaultfd_rwp() was not a compile-time constant, so the compiler could not fold those paths. With an older compiler (gcc 8.5.0, sparc64) the PAGE_NONE reference in move_pages_huge_pmd() survived to codegen: mm/huge_memory.c:2874: _dst_pmd = pmd_modify(_dst_pmd, PAGE_NONE); compiler_types.h:702: error: call to '__compiletime_assert_501' declared with attribute error: BUILD_BUG failed RWP cannot exist without protnone, so return a compile-time false when CONFIG_ARCH_HAS_PTE_PROTNONE is unset; every RWP path then folds away. Link: https://lore.kernel.org/amcitKvUvFYr8W38@thinkstation Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202607250853.VaJWGLeA-lkp@intel.com/ Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Hildenbrand <david@kernel.org> Cc: James Houghton <jthoughton@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Liam Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Mike Rapoport (Microsoft) <rppt@kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Xu <peterx@redhat.com> Cc: Sean Christopherson <seanjc@google.com> Cc: SeongJae Park <sj@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm: page_alloc: move capture_control to the page allocatorVlastimil Babka (SUSE)
The compaction capturing code assumes the allocation request order and compaction target order are the same. That won't be true once defrag_mode promotes sub-block allocations to pageblock-order compaction: compaction targets the larger order, while capture should remain at the original allocation order. Move the capture_control to the page allocator and give it its own copies of what the page freeing path matches against - zone, migratetype and the allocation order - rather than reaching into compaction's live compact_control. __alloc_pages_direct_compact() fills in migratetype and order, and installs and hides current->capture_control around the whole compaction call; try_to_compact_pages() aims capc->zone at each zone while it is being compacted. compact_zone_order() no longer deals with capture at all. Pass the capture_control through try_to_compact_pages() / compact_zone_order() in place of the bare struct page **. No functional change. Link: https://lore.kernel.org/20260722150006.3848560-4-hannes@cmpxchg.org Fixes: e3aa7df331bc ("mm: page_alloc: defrag_mode") Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Co-developed-by: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Reviewed-by: Gregory Price <gourry@gourry.net> Cc: Brendan Jackman <brendan.jackman@linux.dev> Cc: Brendan Jackman <jackmanb@google.com> Cc: David Hildenbrand <david@kernel.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Zi Yan <ziy@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/damon: update outdated comment about DAMOS filter handlingSong Hu
The kernel-doc comment above enum damos_filter_type states that only the anon and memcg type filters are handled by damon_operations (and therefore accounted as 'tried'), and that DAMON_OPS_VADDR and DAMON_OPS_FVADDR do not support those two filter types. Neither is accurate anymore. damos_filter_for_ops() routes every filter type except ADDR and TARGET to the operations layer, and the VADDR and FVADDR operations (the latter being a copy of the former) handle all of those types through damos_folio_filter_match() / damos_va_filter_out(). Update the comment to match the code. Link: https://lore.kernel.org/20260721140011.269802-1-sj@kernel.org Signed-off-by: Song Hu <husong@kylinos.cn> Reviewed-by: SJ Park <sj@kernel.org> Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/memory: move pte_install_uffd_wp_if_needed() into memory.cDev Jain
Patch series "Batch unmap of uffd-wp file folios", v2. Currently, batched unmapping is supported if: 1) folio is a file folio, not belonging to uffd-wp VMA 2) folio is anonymous and not swapbacked (lazyfree), not belonging to uffd-wp VMA So the cases which are not supported are 1) folio belonging to uffd-wp VMA 2) folio is anonymous and swapbacked It is easy to see that this adds a lot of cognitive load while reading try_to_unmap_one - we need to remember throughout whether nr_pages == 1 or > 1. The uffd-wp handling in try_to_unmap_one is regarding preserving the uffd-wp state for file folios via pte_install_uffd_wp_if_needed (for anon folio, we handle that while constructing the swap pte). Stop special casing on uffd-wp VMAs by simply adding batching support to pte_install_uffd_wp_if_needed. This patch (of 3): pte_install_uffd_wp_if_needed() has grown too large for mm_inline.h. Move it to memory.c. This helper is only used inside mm/, so declare it in mm/internal.h instead of a public header. While at it, convert the comment to kerneldoc and rename the local arguments from pte/pteval to ptep/pte so the pointer and PTE value are easier to distinguish. Link: https://lore.kernel.org/20260720065508.2695106-1-dev.jain@arm.com Link: https://lore.kernel.org/20260720065508.2695106-2-dev.jain@arm.com Signed-off-by: Dev Jain <dev.jain@arm.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: Barry Song <baohua@kernel.org> Cc: Harry Yoo <harry@kernel.org> Cc: Jann Horn <jannh@google.com> Cc: Kairui Song <kasong@tencent.com> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Rik van Riel <riel@surriel.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Wei Xu <weixugc@google.com> Cc: Yuanchu Xie <yuanchu@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/huge_memory: fold split_folio_to_list_to_order() into split_folio_to_order()Kiryl Shutsemau (Meta)
split_folio_to_list_to_order() had no direct callers; its only user was split_folio_to_order(), which always passed a NULL list. Fold it into split_folio_to_order() and call split_huge_page_to_list_to_order() directly. No functional change. Link: https://lore.kernel.org/20260716100345.473473-3-kirill@shutemov.name Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Acked-by: Usama Arif <usama.arif@linux.dev> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Nico Pache <npache@redhat.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/huge_memory: remove unused can_split_folio()Kiryl Shutsemau (Meta)
Patch series "mm/huge_memory: drop dead split helper variants". Two trivial cleanups in the folio split API, found while auditing the split helpers for the inode UAF fix [1]: - can_split_folio() is dead: only the !THP stub remains, no definition under CONFIG_TRANSPARENT_HUGEPAGE and no callers. Leftover from an earlier cleanup. - split_folio_to_list_to_order() has no direct callers; its only user is split_folio_to_order(), which always passes a NULL list. Fold it. No functional change. This patch (of 2): can_split_folio() has no callers and no definition under CONFIG_TRANSPARENT_HUGEPAGE; only the !THP stub remains, left behind by an earlier cleanup. Remove it. No functional change. Link: https://lore.kernel.org/20260716100345.473473-1-kirill@shutemov.name Link: https://lore.kernel.org/20260716100345.473473-2-kirill@shutemov.name Link: https://lore.kernel.org/linux-mm/aldjhtfVByHDQXe6@thinkstation [1] Link: https://lore.kernel.org/linux-mm/20260714122344.351895-1-kirill@shutemov.name [2] Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Acked-by: Usama Arif <usama.arif@linux.dev> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Nico Pache <npache@redhat.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm: introduce pud_is_huge() helperKefeng Wang
Patch series "mm: mincore: misc cleanups", v3. This series cleans up and simplifies the mincore. Most importantly, it removes the historical special behavior that always reports VM_PFNMAP pages as non-resident. This patch (of 6): Introduce the pud_is_huge() helper function to check whether a PUD is a huge PUD or a software leaf entry. Note that, unlike PMD, PUD currently does not support transparent migration entries or device private entries. However, the function still includes `!pud_none()` branches to accommodate potential future implementations. Link: https://lore.kernel.org/20260717091347.1144789-1-wangkefeng.wang@huawei.com Link: https://lore.kernel.org/20260717091347.1144789-2-wangkefeng.wang@huawei.com Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Jann Horn <jannh@google.com> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/mseal: limit scope of mseal address zero to address zeroLorenzo Stoakes (ARM)
Commit 44f65d900698 ("binfmt_elf: mseal address zero") unconditionally provided do_mseal() to any internal kernel caller in order to address a corner case slated for possible removal. It also incorrectly attempts to mseal without checking to see whether the mapping even succeeded. Restrict the scope to the corner case by providing mseal_mmap_page_zero() which asserts the MMAP_PAGE_ZERO personality. Avoid unnecessary checks in the start, end range by abstracting the actual mseal()'ing to mseal_range() and have mseal_mmap_page_zero() call that instead. Also only try to seal the VMA if we mapped the VMA. This isn't strictly necessary as the operation would error out anyway, but it's useless work and could be problematic if me make future changes to mseal semantics. Link: https://lore.kernel.org/20260717-mseal-fixups-v2-2-0daa0014b813@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christian Brauner <brauner@kernel.org> Cc: Jan Kara <jack@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: Kees Cook <kees@kernel.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/page_alloc: remove a couple of VM_BUG_ON()stBrendan Jackman
VM_BUG_ON() is out of favour and on the way to removal, since I recently touched alloc_pages_node_noprof() I am removing that invocation, and also removing the __folio_alloc_node_noprof() one for consistency. If this precondition is violated, the system will soon crash anyway. Link: https://lore.kernel.org/20260715-spin-trylock-followup-v3-4-fc4d246f705d@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Suggested-by: Zi Yan <ziy@nvidia.com> Link: https://lore.kernel.org/all/7F866265-3F2E-4765-B9D4-9AB898A9C4AC@nvidia.com/ Acked-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Cc: Brendan Jackman <brendan.jackman@linux.dev> Cc: David Hildenbrand <david@kernel.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Michal Koutný <mkoutny@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Tejun Heo <tj@kernel.org> Cc: Waiman Long <longman@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/damon/core: hide core-private damon_ctx fieldsSJ Park
'ops', 'probes', 'adaptive_targets', 'schemes', and 'rnd_state' fields of damon_ctx are intended to be used by only the DAMON core layer. However, those are mistakenly not marked as private. Mark as private. Link: https://lore.kernel.org/20260714143544.101305-11-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/damon/core: hide private damon_probe fieldsSJ Park
'filters' and 'list' fields of damon_probe are intended to be used by only the DAMON core layer. However, those are mistakenly not marked as private. Mark as private. Link: https://lore.kernel.org/20260714143544.101305-9-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/damon/core: hide private damon_filter fieldsSJ Park
damon_filter->list is intended to be used by only the DAMON core layer. However, it is mistakenly not marked as private. Mark as private. Link: https://lore.kernel.org/20260714143544.101305-8-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/damon/core: hide private damos fieldsSJ Park
'core_filters', 'ops_filters', 'last_applied' and 'list' fields of damos are intended to be used by only the DAMON core layer. However, those are mistakenly not marked as private. Mark as private. Link: https://lore.kernel.org/20260714143544.101305-7-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/damon/core: hide private damos_filter fieldsSJ Park
damos_filter->list is intended to be used by only the DAMON core layer. However, it is mistakenly not marked as private. Mark as private. Link: https://lore.kernel.org/20260714143544.101305-6-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/damon/core: hide private damos_quota fieldsSJ Park
damos_quota->goals is intended to be used by only the DAMON core layer. But it is mistakenly not marked as private. Mark as private. Link: https://lore.kernel.org/20260714143544.101305-5-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/damon/core: hide private damos_quota_goal fieldsSJ Park
'last_psi_total' and 'list' of damos_quota_goal are intended to be used by only the DAMON core layer. Those are mistakenly not marked as private, though. Mark as private. Link: https://lore.kernel.org/20260714143544.101305-4-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/damon/core: hide private damon_target fieldsSJ Park
'nr_regions', 'regions_list' and 'list' fields of damon_target are intended to be used by only the DAMON core layer. Those are mistakenly not marked as private. Mark as private. Link: https://lore.kernel.org/20260714143544.101305-3-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/damon/core: hide private damon_region fieldsSJ Park
Patch series "mm/damon/core: hide core-private struct fields". DAMON core structs hide core-private fields using 'private:' comment tags. It is incomplete and inconsistent. The linked list heads in a few structs, for example, are intended to be hidden, and always be used using the wrapper macros like damon_for_each_region(). But those were mistakenly marked as non-private. A few core layer-only fields were also mistakenly added as non-private. This only encourages callers to directly use the private fields. It is easy to make mistakes, and difficult to control. Mark all such DAMON core struct fields as private. Patches 1-8 mark the private fields for damon_region, damon_target, damos_quota_goal, damos_quota, damos_filter, damos, damon_filter and damon_probe, respectively. Patch 9 removes DAMON_SYSFS's direct access to core-private field, damon_ctx->ops. Finally patch 10 mark the private fields for damon_ctx. This patch (of 10): damon_region->list is intended to be used by only the DAMON core layer. But it is mistakenly not marked as private. Hide it from the callers by marking it private. Link: https://lore.kernel.org/20260714143544.101305-1-sj@kernel.org Link: https://lore.kernel.org/20260714143544.101305-2-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/vma: update create_init_stack_vma() to use vma_flags_tLorenzo Stoakes
Replace use of the legacy vm_flags_t flags with vma_flags_t values in create_init_stack_vma(). As part of this change we add VMA_STACK_EARLY and VMA_STACK_INCOMPLETE vma_flags_t defines, and slightly rework create_init_stack_vma() for clarity. No functional change intended. Link: https://lore.kernel.org/20260711-b4-vma-flags-mm-v2-9-0fa2357d5431@kernel.org Signed-off-by: Lorenzo Stoakes <ljs@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Lance Yang <lance.yang@linux.dev> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Dave Airlie <airlied@gmail.com> Cc: David Hildenbrand <david@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jan Kara <jack@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Nico Pache <npache@redhat.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm: introduce vma_get_page_prot() and use itLorenzo Stoakes
There's a large number of vm_get_page_prot(vma->vm_flags) invocations. Make life easier by introducing vma_get_page_prot() parameterised by the VMA. This also makes converting vm_get_page_prot() to vma_flags_t easier. Also update the userland VMA tests to reflect the change. No functional change intended. Link: https://lore.kernel.org/20260711-b4-vma-flags-mm-v2-8-0fa2357d5431@kernel.org Signed-off-by: Lorenzo Stoakes <ljs@kernel.org> Acked-by: Zi Yan <ziy@nvidia.com> Acked-by: Jani Nikula <jani.nikula@intel.com> # for i915 Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> [DRM] Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Dave Airlie <airlied@gmail.com> Cc: David Hildenbrand <david@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jan Kara <jack@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: Lance Yang <lance.yang@linux.dev> Cc: Mike Rapoport <rppt@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Nico Pache <npache@redhat.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Suren Baghdasaryan <surenb@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/vma: rename vma_get_page_prot to vma_flags_to_page_protLorenzo Stoakes
Having vma_get_page_prot() refer to VMA flags and vma_set_page_prot() refer to a VMA is confusing. Rename vma_get_page_prot() to vma_flags_to_page_prot() to resolve this confusion. No functional change intended. Link: https://lore.kernel.org/20260711-b4-vma-flags-mm-v2-7-0fa2357d5431@kernel.org Signed-off-by: Lorenzo Stoakes <ljs@kernel.org> Reviewed-by: Lance Yang <lance.yang@linux.dev> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Dave Airlie <airlied@gmail.com> Cc: David Hildenbrand <david@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jan Kara <jack@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Nico Pache <npache@redhat.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm: update generic_get_unmapped_area[_topdown]() to use vma_flags_tLorenzo Stoakes
As part of the changes converting VMA flags from a system word size to a bitmap, extend this change to generic_get_unmapped_area() and generic_get_unmapped_area_topdown(), which also allows us to convert stack_guard_placement() as well. We retain arch_get_unmapped_area() and arch_get_unmapped_area_topdown() as-is for now, using legacy_to_vma_flags() as necessary to do so. No functional change intended. Link: https://lore.kernel.org/20260711-b4-vma-flags-mm-v2-4-0fa2357d5431@kernel.org Signed-off-by: Lorenzo Stoakes <ljs@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Lance Yang <lance.yang@linux.dev> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Dave Airlie <airlied@gmail.com> Cc: David Hildenbrand <david@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jan Kara <jack@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Nico Pache <npache@redhat.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm: convert __get_unmapped_area() to use vma_flags_tLorenzo Stoakes
Update __get_unmapped_area() to be parameterised by vma_flags_t rather than vm_flags_t as part of the effort to move VMA flags from a system word to a bitmap. We cascade the changes up to arch_get_unmapped_area_topdown() and arch_get_unmapped_area(), where, for now, we use vma_flags_to_legacy() in order to propagate the VMA flags. No functional change intended. Link: https://lore.kernel.org/20260711-b4-vma-flags-mm-v2-3-0fa2357d5431@kernel.org Signed-off-by: Lorenzo Stoakes <ljs@kernel.org> Reviewed-by: Lance Yang <lance.yang@linux.dev> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Dave Airlie <airlied@gmail.com> Cc: David Hildenbrand <david@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jan Kara <jack@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Nico Pache <npache@redhat.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/vma: update do_mmap() to use vma_flags_tLorenzo Stoakes
The core do_mmap() function accepts a vm_flags_t parameter which it then manipulates before passing to mmap_region() to do the heavy lifting of the memory mapping. Update do_mmap() to instead accept a vma_flags_t parameter, and adjust all the logic within do_mmap() to manipulate this instead. This is as part of the ongoing effort to convert VMA flags from a system word size to a bitmap type which allows us to unrestrict the number of VMA flags, as well as gain control over how VMA flag manipulation occurs. We do not cascade these changes to all functions which accept vm_flags_t, but rather use vma_flags_to_legacy() where necessary, specifically deferring converting calc_vm_prot_bits(), calc_vm_flag_bits() and __get_unmapped_area() to vma_flags_t. Also utilise the new vma_flags_can_grow() predicate which correctly handles the case of architectures without upward growing stacks. As part of this change, introduce VMA_SHADOW_STACK so we can correctly handle the case of the shadow stack not being defined. No functional change intended. Link: https://lore.kernel.org/20260711-b4-vma-flags-mm-v2-2-0fa2357d5431@kernel.org Signed-off-by: Lorenzo Stoakes <ljs@kernel.org> Reviewed-by: Lance Yang <lance.yang@linux.dev> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Dave Airlie <airlied@gmail.com> Cc: David Hildenbrand <david@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jan Kara <jack@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Nico Pache <npache@redhat.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm: introduce vma_flags_can_grow() and vma_can_grow()Lorenzo Stoakes
Patch series "mm: convert more vm_flags_t users to vma_flags_t", v2. This series makes further progress in converting usage of the deprecated vm_flags_t type to its replacement, vma_flags_t. It focuses on mm, though updates some users of mm APIs also. It updates: * The core do_mmap() code path for VMA mapping. * Unmapped area logic. * The usage of mm->def_vma_flags. * VMA page protection bit logic. * General usage of VMA flags in core mm code, mlock, mprotect, mremap. This patch (of 13): These test whether the VMA has stack semantics, i.e. is able to grow upwards or downwards depending on the architecture. In order to account for arches which do not support upward-growing stacks, introduce VMA_GROWSUP whose definition depends on the architecture supporting it, and use vma_flags_test_single_mask() in vma_flags_can_grow() to account for this. No functional change intended. Link: https://lore.kernel.org/20260711-b4-vma-flags-mm-v2-0-0fa2357d5431@kernel.org Link: https://lore.kernel.org/20260711-b4-vma-flags-mm-v2-1-0fa2357d5431@kernel.org Signed-off-by: Lorenzo Stoakes <ljs@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Lance Yang <lance.yang@linux.dev> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Dave Airlie <airlied@gmail.com> Cc: David Hildenbrand <david@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jan Kara <jack@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: Lance Yang <lance.yang@linux.dev> Cc: Mike Rapoport <rppt@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Nico Pache <npache@redhat.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Zi Yan <ziy@nvidia.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/memory_hotplug: add offline_and_remove_memory_ranges()Gregory Price
offline_and_remove_memory() handles a single contiguous range. Callers that manage a device composed of several ranges (dax/kmem) currently have to call it in a loop, which gives up atomicity. In addition to pushing rollback logic into the driver, the lack of atomicity creates a race condition between system daemons trying to manage the same resource: - Manager 1: Offlines memory blocks. Removes device. ^^^^ - Manager 2: Detects offline memory blocks, re-onlines them. Add offline_and_remove_memory_ranges(), which takes an array of ranges and processes them as one operation under a single lock_device_hotplug(): - Phase 1 offlines every block of every range. - Phase 2 removes the ranges only if all ranges are offline. - If any offline fails, the whole operation is reverted. This gives callers all-or-nothing semantics for the offline step, so a failed or interrupted unplug leaves the device in a consistent state. This also resolves the battling managers race - the second manager's operation simply fails when the block is destroyed / cannot be onlined. offline_and_remove_memory() becomes a thin wrapper that passes its single range to the new helper, so the offline/rollback logic lives in one place. Link: https://lore.kernel.org/20260712154505.3564379-7-gourry@gourry.net Signed-off-by: Gregory Price <gourry@gourry.net> Suggested-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Dan Williams <djbw@kernel.org> Cc: Alison Schofield <alison.schofield@intel.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Hannes Reinecke <hare@suse.de> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pankaj Gupta <pankaj.gupta@amd.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/memory_hotplug: add __add_memory_driver_managed() with online_type argGregory Price
Existing callers of add_memory_driver_managed cannot select the preferred online type (ZONE_NORMAL vs ZONE_MOVABLE), requiring it to hot-add memory as offline blocks, and then follow up by onlining each memory block individually. Most drivers prefer the system default, but the CXL driver wants to plumb a preferred policy through the dax kmem driver. Refactor APIs to add a new interface which allows the dax kmem module to select a preferred policy. Overriding the configured auto-online policy is only safe for known in-tree modules, where we know the override reflects a different, user-requested policy. We do not want arbitrary out-of-tree drivers silently overriding the system-wide onlining policy, so restrict the new interface to the kmem module using EXPORT_SYMBOL_FOR_MODULES() rather than a plain EXPORT_SYMBOL_GPL(). Other in-tree modules (e.g. cxl_core) can be added to the allowed list as the need arises. Refactor add_memory_driver_managed, extract __add_memory_driver_managed - Add proper kernel-doc for add_memory_driver_managed while refactoring - New helper accepts an explicit online_type. - New helper validates online_type is between OFFLINE and ONLINE_MOVABLE Refactor: add_memory_resource, extract __add_memory_resource - new helper accepts an explicit online_type Original APIs now explicitly pass the system-default to new helpers. No functional change for existing users. Link: https://lore.kernel.org/20260712154505.3564379-6-gourry@gourry.net Signed-off-by: Gregory Price <gourry@gourry.net> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Dan Williams <djbw@kernel.org> Cc: Alison Schofield <alison.schofield@intel.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Hannes Reinecke <hare@suse.de> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/memory_hotplug: export mhp_get_default_online_typeGregory Price
Drivers which may pass hotplug policy down to DAX need MMOP_ symbols and the mhp_get_default_online_type function for hotplug use cases. Some drivers (cxl) co-mingle their hotplug and devdax use-cases into the same driver code, and chose the dax_kmem path as the default driver path - making it difficult to require hotplug as a predicate to building the overall driver (it may break other non-hotplug use-cases). Export mhp_get_default_online_type function to allow these drivers to build when hotplug is disabled and still use the DAX use case. In the built-out case we simply return MMOP_OFFLINE as it's non-destructive. The internal function can never return -1 either, so we choose this to allow for defining the function with 'enum mmop'. Link: https://lore.kernel.org/20260712154505.3564379-5-gourry@gourry.net Signed-off-by: Gregory Price <gourry@gourry.net> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Dan Williams <djbw@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Alison Schofield <alison.schofield@intel.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Hannes Reinecke <hare@suse.de> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pankaj Gupta <pankaj.gupta@amd.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/memory_hotplug: add mhp_online_type_to_str() and export string helpersGregory Price
Add mhp_online_type_to_str() as the inverse of mhp_online_type_from_str(), and export both so a driver can render and parse the memory online type through its own sysfs interface. Link: https://lore.kernel.org/20260712154505.3564379-3-gourry@gourry.net Signed-off-by: Gregory Price <gourry@gourry.net> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Dan Williams <djbw@kernel.org> Cc: Alison Schofield <alison.schofield@intel.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Hannes Reinecke <hare@suse.de> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pankaj Gupta <pankaj.gupta@amd.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-06mm/memory: add memory_block_aligned_range() helperGregory Price
Patch series "dax/kmem: atomic whole-device hotplug via sysfs", v7. The dax kmem driver onlines memory during probe using the system default policy, with no atomic control for the state of an entire region at runtime - only by toggling individual memory blocks. Offlining and removing a whole region therefore races with other userland controllers that interfere between the two steps. This series adds a sysfs "state" attribute for atomic whole-device hotplug control, plus the mm and dax plumbing to support it. Transitions are atomic across every range of the device. The state names mirror the per-block memoryX/state ABI with one modification: - "unplugged": memory blocks are not present - "online": online as system RAM, zone chosen by the kernel - "online_kernel": online in ZONE_NORMAL - "online_movable": online in ZONE_MOVABLE "offline" (blocks present but offline) is reportable for backward compatibility but is not writable because it entices the race condition we are trying to solve (separate atomic steps for offline and unplug). 'unplugged' (atomic offline+remove of the whole device) is the new capability provided by the new kmem sysfs attribute. dax/kmem probe still creates the memory blocks by default when the default policy is "offline", to preserve backwards compatibility. This patch (of 10): Memory hotplug operations require ranges aligned to memory block boundaries. This is a generic operation for hotplug. Add memory_block_aligned_range() as a common helper in <linux/memory.h> that aligns the start address up and end address down to memory block boundaries. Guard against end underflow when the range falls below the first memory block boundary, returning an empty range instead. Update dax/kmem to use this helper. Link: https://lore.kernel.org/20260712154505.3564379-1-gourry@gourry.net Link: https://lore.kernel.org/20260712154505.3564379-2-gourry@gourry.net Signed-off-by: Gregory Price <gourry@gourry.net> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Dan Williams <djbw@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Alison Schofield <alison.schofield@intel.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Hannes Reinecke <hare@suse.de> Cc: Pankaj Gupta <pankaj.gupta@amd.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-07power: supply: add stubs for notifier registration helpersElson Serrao
power_supply_reg_notifier() and power_supply_unreg_notifier() are declared unconditionally, with no fallback when CONFIG_POWER_SUPPLY is disabled. Any driver that calls them unconditionally fails to link: ERROR: modpost: "power_supply_unreg_notifier" [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: modpost: "power_supply_reg_notifier" [drivers/usb/dwc3/dwc3.ko] undefined! Fix this by adding stub functions for these calls. Fixes: 7c87ef27af79 ("usb: dwc3: avoid probe deferral when USB power supply is not available") Reported-by: Randy Dunlap <rdunlap@infradead.org> Closes: https://lore.kernel.org/all/a9dd53b3-0666-404a-99e0-76617ae3f944@infradead.org/ Signed-off-by: Elson Serrao <elson.serrao@oss.qualcomm.com> Tested-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260805185401.3625514-1-elson.serrao@oss.qualcomm.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-08-06drm/ttm: Hook up a cgroup-aware reclaim callback for the dmem controllerThomas Hellström
Add ttm_bo_evict_cgroup() to evict buffer objects charged to a specific dmem cgroup pool from a resource manager's LRU until a byte target is met. Add ttm_resource_manager_set_dmem_region() to associate a dmem cgroup region with a resource manager; drivers supply their own dmem_cgroup_ops with ttm_resource_manager_dmem_reclaim as the reclaim function and the manager pointer as reclaim_priv in the dmem_cgroup_init to wire up TTM eviction as the reclaim callback. The eviction context is interruptible; signals abort the operation and propagate back through the write() syscall. Introduce a new mode for the bo LRU walker so that sleeping locks can be taken. This can be used when the caller doesn't hold any previous dma_resv locks, and where it intends to hold at most one lock at a time. Like the rest of the TTM eviction this should sooner than later be converted to full WW transactions. v3: - Fix ttm_resource_manager_set_dmem_region() storing an error pointer in man->cg unconditionally. (Sashiko-bot) - Fix kernel-doc function name format for ttm_bo_evict_cgroup() and ttm_resource_manager_set_dmem_region(). v5: - Rebased on the introduction of struct dmem_cgroup_init. - Handle NULL region in ttm_resource_manager_set_dmem_region() to clear the reclaim callback, preventing use-after-free when the manager is torn down while the dmem region outlives it. (Sashiko-bot) - Return 0 on any progress (even partial eviction), -ENOSPC only when nothing was freed; fixes callers that expected 0 on partial success. - Document that the reclaim callback should return 0 if some progress was made, -ENOSPC if no progress at all, or another error for fatal failures. v8: - Fix ttm_resource_manager_set_dmem_region() using IS_ERR_OR_NULL(), which skipped the assignment for a NULL region and thus never cleared man->cg. Use IS_ERR() so that a NULL region detaches the region as the kernel-doc and the v5 changelog intended. (Sashiko-bot) v9: - Don't leak cgroup charges for bos that may have survived dmemcg region fini. - Drop the misleading "Capture size before eviction in case res is cleared" comment in ttm_bo_evict_cb(). (Maarten Lankhorst) Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v7 Tested-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Link: https://patch.msgid.link/20260725100036.2372-5-thomas.hellstrom@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-08-06cgroup/dmem: Add reclaim callback for lowering max below current usageThomas Hellström
Add an optional reclaim callback to struct dmem_cgroup_region. When dmem.max is set below the current usage of a cgroup pool, the new limit is applied immediately (so that concurrent allocations are throttled while reclaim is in progress) and then the driver is asked to evict memory to bring usage back below the limit. Reclaim is attempted up to a bounded number of times. No error is returned to userspace if usage remains above the limit after reclaim, and a pending signal will abort the reclaim loop early. This matches the behavior of memory.max in the memory cgroup controller. Also honor O_NONBLOCK so that if that flag is set during the max value write, no reclaim is initiated. The idea is to avoid charging the reclaim cost to the writer of the max value. v2: - Write max before reclaim is attempted (Maarten) - Let signals abort the reclaim without error (Maarten) - If a new max value is written with the O_NONBLOCK flag, reclaim is not attempted (Maarten) - Extract region from the pool parameter rather than passing it explicitly to set_resource_xxx(). v3: - Use an rw_semaphore (unregister_sem) to protect reclaim callbacks against concurrent region unregistration: readers (reclaim) hold the read side; dmem_cgroup_unregister_region() takes the write side to drain in-flight callbacks before returning. (Sashiko-bot) v5: - Rebased on the introduction of struct dmem_cgroup_init. - Use nonblock=true in reset_all_resource_limits() to avoid sleeping inside rcu_read_lock() in dmemcs_offline(). (Sashiko-bot) - Compare usage against the truncated limit value stored in cnt.max, not the original u64. (Sashiko-bot) - Use a DMEM_MAX_RECLAIM_RETRIES (16) retry budget instead of 5, matching the memcg controller's MAX_RECLAIM_RETRIES. Only -ENOSPC (no progress) counts against the retry budget; other errors terminate the loop immediately. v6: - Fix dmem_cgroup_ops->reclaim docstring: -ENOSPC does not stop reclaim immediately but is retried up to DMEM_MAX_RECLAIM_RETRIES times; only other negative errors terminate the loop. (Sashiko-bot) v7: - Replace the per-region rw_semaphore with a static SRCU domain (dmemcg_srcu). SRCU is a better fit than rwsem for this use: it avoids the per-region lock overhead on every reclaim call, and synchronize_srcu() at unregister time is a rare operation. (Maarten) - Trim in-function comments to focus on what rather than how. Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Tested-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Link: https://patch.msgid.link/20260725100036.2372-4-thomas.hellstrom@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-08-06cgroup/dmem: Introduce struct dmem_cgroup_init for region initializationThomas Hellström
Replace the bare u64 size argument to dmem_cgroup_register_region() and drmm_cgroup_register_region() with a const struct dmem_cgroup_init * pointer. The struct currently carries only the size field, but using a struct makes the API extensible: future callers can supply additional initialization parameters without adding more positional arguments. Update all in-tree callers (amdgpu, xe) to use a compound-literal initializer. v5: - Commit introduced. Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Tested-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Link: https://patch.msgid.link/20260725100036.2372-3-thomas.hellstrom@linux.intel.com Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-08-06Merge tag 'for-7.2-rc6-fixup-worker-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull Btrfs Fixes 2: Electric Boogaloo from David Sterba: "This brings back the fixup worker infrastructure. It's a mechanism to detect pages/folios that are marked dirty without filesystem knowledge and require COW fixup. The consequence of not doing so is silent data loss. The first patch covers the scenarios in detail, also reflecting folio API port and subpage block size support added in recent years. The original fixup worker was only for pages. The patch is relatively big, half of the code is debugging and support code, the rest is the core design around the detection and fix. The second patch handles an unlikely case when there's work left during unmount" * tag 'for-7.2-rc6-fixup-worker-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: flush the fixup workers during close_ctree btrfs: trigger cow fixup via dirty_folio()
2026-08-06Merge tag 'wireless-next-2026-08-06' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== Quite a bunch more work, of note: - iwlwifi: new FW version support - mt76: - mt7928 support - mt7925 NAN support - mt7996 AP powersave improvements - rtw89: - LED support - RTL8922DE support - dual-BT coex for RTL8922D - ath12k: AHB platform MultiPD support - cfg80211: pre-assign cookies for operations - mac80211: AQL support for multicast * tag 'wireless-next-2026-08-06' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (403 commits) wifi: nxpwifi: bound uAP association event IEs to the event buffer wifi: nxpwifi: detach sync command buffer on interrupted wait wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control() wifi: rsi: Fix types to appease CFI wifi: mac80211: skip default WMM setup for AP_VLAN links wifi: nxpwifi: fix multiple static analysis errors and warnings wifi: morsemicro: MM81X should be invisible and selected by its users wifi: nxp: NXPWIFI should be invisible and selected by its users wifi: cfg80211: stop PMSR before P2P and NAN teardown wifi: mac80211: disconnect on CSA to channel 0 wifi: brcmfmac: fix P2P action frame handling without device vif wifi: brcmfmac: Set DMA direction for msgbuf packet IDs wifi: brcmfmac: validate msgbuf flowring IDs before use wifi: mac80211: fix RCU usage in peer probing wifi: mac80211: fix RCU dereference in throughput estimate wifi: wilc1000: validate monitor transmit frame headers wifi: mac80211: skip unused probe response countdown offsets wifi: zd1211rw: reject secondary interfaces to prevent conflicts wifi: nl80211: clean up color-change beacon data on errors wifi: mac80211: send TWT teardown to peer after setup TX failure ... ==================== Link: https://patch.msgid.link/20260806121304.190084-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-7.2-rc7). No conflicts, or adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06Merge tag 'net-7.2-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Including fixes from netfilter. Looks like our attempt to keep the PRs smaller have only prevented this one from getting even bigger. In the last 9 days there were 405 postings explicitly tagged with [PATCH net], vs 687 with [PATCH net-next]. 37% of posted patches being fixes is pretty crazy, and that's likely undercounting because LLM "researchers" more often post fixes without knowing to tag the patches for specific trees. I don't have historic data. In any case, we keep adjusting the criteria. The next PR will be smaller. Current release - regressions: - net: defer netdev KOBJ_ADD uevent until the device is published, previously rtnl_lock would serialize the accesses vs publishing - net: explicitly cancel work to avoid races with ref tracker exit - qrtr: ns: raise lookup limit to 128 - eth: hns3: fix speed configuration residue after driver reload Previous releases - regressions: - tcp: do not change rcv_ssthresh in tcp_measure_rcv_mss(), regressed flows with MSS and scaling_ratio variability - Revert "net: thunderbolt: Enable end-to-end flow control also in transmit", broke some platforms (no packets coming thru) - eth: stmmac: resume PHY before hardware setup when opening the interface Previous releases - always broken: - another pile of fixes for less common protocols (SCTP, TLS, SMC etc.) - close a couple of AF_PACKET bugs and ways it can build skbs problematic for the rest of the stack - bridge: mrp: fix uninitialised bytes on the wire - net: devmem: prevent net-iov / page mixing, avoid crashes - eth: atlantic: free RX pages of consumed but not refilled buffers" * tag 'net-7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (116 commits) igc: fix netdev not re-attached after resume if interface is down tls: don't abort the connection on signal-interrupted sends net: avoid theoretical races with ref drain net: Defer netdev KOBJ_ADD uevent until the device is published MAINTAINERS: dpll: zl3073x: replace Prathosh Satish with Min Li sctp: clear control chunk transport if it is being removed net/atm: fix slab-out-of-bounds read in vcc_setsockopt() s390/ism: Fix UAF of sba and ieq during ism_dev_exit() packet: use consistent hard_header_len in TX_RING send path packet: use consistent hard_header_len in non-ring send paths net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header bnge: Fix resource leak in bnge_init_nic() error path ptp: ocp: Fix board ID over-read tls: rx: restore msg_iter before TLS 1.3 optimistic retry selftests: tls: add a test for splicing onto a full plaintext record tls: don't leave a full plaintext sk_msg ring unpushed xdp: reject clones that overrun skb_shared_info tailroom mptcp: reclaim forward-allocated memory on RX path errors mptcp: fastopen: only mark MPTFO subflows with SYN data mptcp: pm: fix memory leak from alloc-during-teardown race ...
2026-08-06spi: add new_device/delete_device sysfs interfaceMark Brown
Vishwaroop A <va@nvidia.com> says: Add I2C-style new_device/delete_device sysfs attributes to SPI host controllers, allowing userspace to instantiate and remove SPI devices at runtime without device-tree changes. Patch 1 adds the new_device/delete_device attributes and the supporting infrastructure (userspace_clients list, manual sysfs group registration). Patch 2 adds the ABI and user-facing documentation. Link: https://lore.kernel.org/linux-spi/20260728191056.2337791-1-va@nvidia.com/ # v8 Link: https://lore.kernel.org/linux-spi/20260728030541.2279518-1-va@nvidia.com/ # v7 Link: https://lore.kernel.org/linux-spi/cover.1784000000.git.va@nvidia.com/ # v6 Link: https://lore.kernel.org/linux-spi/20260517201602.498135-1-va@nvidia.com/ # v5 Link: https://lore.kernel.org/linux-tegra/909f0c92-d110-4253-903e-5c81e21e12c9@nvidia.com/ Link: https://patch.msgid.link/20260803104614.2548375-1-va@nvidia.com
2026-08-06spi: add new_device/delete_device sysfs interfaceVishwaroop A
Development boards such as the Jetson AGX Orin expose SPI buses on expansion headers (e.g. the 40-pin header) so that users can connect and interact with SPI peripherals from userspace. The standard way to get /dev/spidevB.C character device nodes for this purpose is to register spi_device instances backed by the spidev driver. Today there is no viable way to do this on upstream kernels: - The spidev driver rejects the bare "spidev" compatible string in DT, since spidev is a Linux software interface and not a description of real hardware. - Vendor-specific compatible strings (e.g. "nvidia,tegra-spidev") have been rejected by DT maintainers for the same reason. The I2C subsystem solved an analogous problem by exposing new_device/delete_device sysfs attributes on each adapter. Add the same interface to SPI host controllers, so that userspace (e.g. a systemd unit at boot) can instantiate SPI devices at runtime without needing anything in device-tree. The new_device file accepts: <modalias> <chip_select> [<max_speed_hz> [<mode>]] where chip_select is required, while max_speed_hz and mode are optional and default to 0 if omitted. max_speed_hz == 0 is clamped to the controller's maximum by spi_setup(); mode == 0 selects SPI mode 0 (CPOL=0, CPHA=0). The modalias is used both as the device identifier and as a driver_override, so that the device binds to the named driver directly. This is necessary because some drivers like spidev deliberately exclude generic names from their id_table. Devices created this way are limited compared to those declared via DT or board files: - No IRQ is assigned (the device gets IRQ 0 / no interrupt). - No platform_data or device properties are attached. - No OF node is associated with the device. These limitations are acceptable for spidev, which only needs a registered spi_device to expose a character device to userspace. Only devices created via new_device can be removed through delete_device; DT and platform devices are unaffected. The sysfs attributes are gated behind CONFIG_SPI_DYNAMIC since this feature adds a new way of dynamically instantiating and removing SPI devices, and the add_lock locking in spi_unregister_controller() is already conditional on CONFIG_SPI_DYNAMIC. The userspace sysfs group is created manually as the last step of spi_register_controller() and removed as the first step of spi_unregister_controller(). Removing the group before taking add_lock means kernfs_drain() completes any in-flight new_device_store()/delete_device_store() calls before add_lock is acquired, so unregister never blocks on a store that is itself waiting for add_lock and no store can be touching an spi_device that is about to be torn down. Non-sysfs callers of __spi_add_device() (DT/ACPI dynamic add, ancillary registration) continue to be protected by the pre-existing !device_is_registered(&ctlr->dev) check added in commit ddf75be47ca7 ("spi: Prevent adding devices below an unregistering controller"): device_del(&ctlr->dev) runs inside add_lock in spi_unregister_controller() so state_in_sysfs flips to 0 before add_lock is released. Link: https://lore.kernel.org/linux-tegra/909f0c92-d110-4253-903e-5c81e21e12c9@nvidia.com/ Signed-off-by: Vishwaroop A <va@nvidia.com> Link: https://patch.msgid.link/20260803104614.2548375-2-va@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06packet: use consistent hard_header_len in non-ring send pathsQihang Tang
packet_snd() reads dev->hard_header_len multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes. For SOCK_RAW, packet_snd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write. packet_sendmsg_spkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb. Add LL_RESERVED_SPACE_EX() for callers that already saved a header length. Read hard_header_len once in packet_snd() and use it for allocation and construction. In packet_sendmsg_spkt(), preserve the allocation-time value through the device lookup retry. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here. Fixes: b84bbaf7a6c8 ("packet: in packet_snd start writing at link layer allocation") Cc: stable@vger.kernel.org Signed-off-by: Qihang Tang <q.h.hack.winter@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260805125729.19220-3-q.h.hack.winter@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06net: remove CAP_SYS_RAWIO zero-padding in dev_validate_headerQihang Tang
dev_validate_header() reads dev->hard_header_len directly when zero-padding short link layer headers for CAP_SYS_RAWIO holders: if (capable(CAP_SYS_RAWIO)) { memset(ll_header + len, 0, dev->hard_header_len - len); return true; } Packet send paths call dev_validate_header() on skbs whose headroom was allocated from an earlier hard_header_len read. If the device is reconfigured so that dev->hard_header_len increases before validation, the memset writes past the reserved buffer, an out-of-bounds write. This out-of-bounds write is masked in some SOCK_RAW paths today because the same concurrent increase can first make skb_push() exceed the reserved headroom and trigger skb_under_panic(). Remove the zero-padding branch before making those hard_header_len reads consistent, so the snapshot fixes do not turn a loud panic into a silent overwrite. This path is only reached for variable length L2 protocols, where len < hard_header_len but len >= min_header_len. No remaining in-tree variable length L2 protocol implements header_ops->validate, and the CAP_SYS_RAWIO bypass that zero-pads and accepts short headers has no real value beyond allowing testing of intentionally malformed input. Drop the CAP_SYS_RAWIO branch. The remaining reads of dev->hard_header_len in dev_validate_header() are comparisons only and have no memory safety impact. Suggested-by: Willem de Bruijn <willemb@google.com> Fixes: 2793a23aacbd ("net: validate variable length ll headers") Cc: stable@vger.kernel.org Signed-off-by: Qihang Tang <q.h.hack.winter@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260805125729.19220-2-q.h.hack.winter@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06ASoC: wm8904: don't use "/**" for non-kernel-doc commentsRandy Dunlap
Modify these errant comments to use "/*" since they are not kernel-doc comments. Warning: include/sound/wm8904.h:119 This comment starts with '/**', but isn't a kernel-doc comment. * DRC configurations are specified with a label and a set of register Warning: ../include/sound/wm8904.h:134 This comment starts with '/**', but isn't a kernel-doc comment. * ReTune Mobile configurations are specified with a label, sample Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260715000525.739874-15-rdunlap@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06ASoC: qcom: audioreach: use C-style "/*" commentRandy Dunlap
Modify the "/**" to use "/*" instead since this is not a kernel-doc comment. This avoids all kernel-doc warnings in this header file: Warning: include/uapi/sound/snd_ar_tokens.h:61 Cannot find identifier on line: * %AR_TKN_U32_SUB_GRAPH_INSTANCE_ID: Sub Graph Instance Id Warning: ../include/uapi/sound/snd_ar_tokens.h:62 Cannot find identifier on line: * Warning: ../include/uapi/sound/snd_ar_tokens.h:63 Cannot find identifier on line: * %AR_TKN_U32_SUB_GRAPH_PERF_MODE: Performance mode of subgraph Warning: include/uapi/sound/snd_ar_tokens.h:64 This comment starts with '/**', but isn't a kernel-doc comment. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/20260715000525.739874-14-rdunlap@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06ASoC: soc-acpi: fix all kernel-doc warningsRandy Dunlap
Add missing "struct" keyword to kernel-doc for structs. Describe @mach_params in struct snd_soc_acpi_mach. Don't document callback parameters with '@' as though they are kernel-doc. These changes avoid all kernel-doc warnings in this header file. Examples: Warning: ../include/sound/soc-acpi.h:77 cannot understand function prototype: 'struct snd_soc_acpi_mach_params' Warning: ../include/sound/soc-acpi.h:101 cannot understand function prototype: 'struct snd_soc_acpi_endpoint' Warning: ../include/sound/soc-acpi.h:115 cannot understand function prototype: 'struct snd_soc_acpi_adr_device' Warning: ../include/sound/soc-acpi.h:132 cannot understand function prototype: 'struct snd_soc_acpi_link_adr' Warning: ../include/sound/soc-acpi.h:209 cannot understand function prototype: 'struct snd_soc_acpi_mach' Warning: include/sound/soc-acpi.h:230 struct member 'mach_params' not described in 'snd_soc_acpi_mach' Warning: include/sound/soc-acpi.h:230 Excess struct member 'card' description in 'snd_soc_acpi_mach' Warning: include/sound/soc-acpi.h:230 Excess struct member 'mach' description in 'snd_soc_acpi_mach' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260715000525.739874-12-rdunlap@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06ASoC: SDCA: correct enum names and add a missing struct fieldRandy Dunlap
Add a kernel-doc comment for @is_volatile in struct sdca_control. Correct 2 malformed enum names to match the enums. Fixes 3 warnings: Warning: include/sound/sdca_function.h:306 expecting prototype for enum sdca_set_index_range. Prototype was for enum sdca_fdl_set_index_range instead Warning: include/sound/sdca_function.h:829 struct member 'is_volatile' not described in 'sdca_control' Warning: include/sound/sdca_function.h:1152 expecting prototype for enum sdca_xu_reset_machanism. Prototype was for enum sdca_xu_reset_mechanism instead Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260715000525.739874-11-rdunlap@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06ALSA: rawmidi: Work around false-positive mutex lockdep warningTakashi Iwai
When opening a legacy rawmidi device for a UMP, it may re-open an existing rawmidi device for appending to a substream, leading to a lockdep warning due to rmidi->open_mutex taken twice -- but the rawmidi devices are completely individual, hence it's a false-positive. For avoiding the warning, modify the helper to open a rawmidi instance with a proper locking subclass from the UMP legacy open. Unfortunately, there is no good way to achieve it with guard(), so reverted to the manual mutex calls again. Reported-by: syzbot+d10d58fc99caa0489796@syzkaller.appspotmail.com Closes: https://lore.kernel.org/6a6a9634.57649fcc.360844.000b.GAE@google.com Link: https://patch.msgid.link/20260806101352.1291581-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-08-06net/sched: reject overly deep qdisc hierarchiesZijie Huang
Deep qdisc hierarchies can lead to excessive recursion in qdisc tree walkers and exhaust the kernel stack. The existing loop check does not cover the create-and-graft path, so a hierarchy can still be extended by creating a new child qdisc below an already deep parent. Store the hierarchy depth in struct Qdisc and update it when qdiscs are grafted. Reject new child qdiscs once the parent is already at the maximum allowed depth. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Suggested-by: Jamal Hadi Salim <jhs@mojatatu.com> Reported-by: Vega <vega@nebusec.ai> Assisted-by: Codex:gpt-5.4 Signed-off-by: Zijie Huang <milkory@outlook.com> Signed-off-by: Ren Wei <enjou1224z@gmail.com> Reviewed-by: Victor Nogueira <victor@mojatatu.com> Link: https://patch.msgid.link/1e9ab39597423fd5d13cfaaf52279b8ee3d9fc3c.1785434373.git.milkory@outlook.com Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>