linux-next.git/include/asm-generic, branch master

Merge branch 'next' of https://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux.git

2026-10-06T10:54:42+00:00

# Conflicts: # mm/memblock.c # mm/mm_init.c

Merge branch 'master' of https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

2026-10-06T10:54:36+00:00

# Conflicts: # Documentation/scheduler/index.rst # arch/arm64/configs/defconfig

Merge branch 'kbuild-for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux.git

2026-10-06T09:38:02+00:00

# Conflicts: # init/Kconfig # scripts/kallsyms.c # scripts/remove-stale-files

mm: rename is_vm_hugetlb_page() to vma_is_hugetlb()

2026-10-05T06:36:20+00:00

The is_vm_hugetlb_page() predicate is badly named - the mapping can span more than a page and it is inconsistent with other VMA predicates that typically are prefixed by vma_. Rename to vma_is_hugetlb() for consistency, and while we're here update some VM_BUG_ON_VMA() to VM_WARN_ON_ONCE_VMA() as to avoid unnecessary oopses. No functional change intended. Link: https://lore.kernel.org/20261003-b4-mmap-prepare-vma-flag-sanify-v4-27-a1f052500fd7@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Andrew Morton Acked-by: Marc Zyngier Acked-by: Claudio Imbrenda Acked-by: Anup Patel Acked-by: Zi Yan Acked-by: David Hildenbrand (Arm) Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Pedro Falcato Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Michal Hocko Cc: Jonathan Corbet Cc: Greg Kroah-Hartman Cc: Dennis Dalessandro Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Paul Moore Cc: Stephen Smalley Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Andrii Nakryiko Cc: Eduard Zingerman Cc: Kumar Kartikeya Dwivedi Cc: Baolin Wang Cc: Nico Pache Cc: Ryan Roberts Cc: Dev Jain Cc: Barry Song Cc: Lance Yang Cc: Usama Arif Cc: Kiryl Shutsemau Cc: Doug Gilbert Cc: James Bottomley Cc: Martin K. Petersen Cc: Simona Vetter Cc: Helge Deller Cc: Sebastian Reichel Cc: John Hubbard Cc: Peter Xu Cc: Masami Hiramatsu Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: Arnaldo Carvalho de Melo Cc: Namhyung Kim Cc: Mark Rutland Cc: Rik van Riel Cc: Harry Yoo Cc: Juri Lelli Cc: Vincent Guittot Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Will Deacon Cc: Aneesh Kumar K.V Cc: Nicholas Piggin Cc: Arnd Bergmann Cc: Muchun Song Cc: Oscar Salvador Cc: Matthew Wilcox (Oracle) Cc: Jan Kara Cc: Oliver Upton Cc: Catalin Marinas Cc: Madhavan Srinivasan Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: Christian Borntraeger Cc: Janosch Frank Cc: Alexander Gordeev Cc: Gerald Schaefer Cc: Heiko Carstens Cc: Vasily Gorbik Cc: David S. Miller Cc: Andreas Larsson Cc: Al Viro Cc: Christian Brauner Cc: Matthew Brost Cc: Joshua Hahn Cc: Rakie Kim Cc: Byungchul Park Cc: Gregory Price Cc: Ying Huang Cc: Alistair Popple Cc: Chris Li Cc: Kairui Song Cc: Kemeng Shi Cc: Nhat Pham Cc: Baoquan He Cc: Youngjun Park Cc: Johannes Weiner Cc: Qi Zheng Cc: Shakeel Butt Cc: Axel Rasmussen Cc: Yuanchu Xie Cc: Wei Xu Cc: Chengming Zhou Cc: Michal Hocko Cc: Miklos Szeredi Cc: Xu Xin

mm: remove hugetlb_inline.h

2026-10-05T06:36:20+00:00

This header really makes little sense - every place it is included mm.h is also included, and the header itself includes mm.h, so it does nothing to reduce header size. It also oddly does an #ifdef around checking VMA_HUGETLB_BIT, however VMA_HUGETLB_BIT is unconditionally available, and will never be set if hugetlb is not enabled. Simply remove the header, eliminate the odd ifdeffery and place the predicates in mm.h. The naming of these predicates is odd, but to keep changes separate, we will address this in a separate patch. The file was never put into MAINTAINERS so there's no change required there. No functional change intended. Link: https://lore.kernel.org/20261003-b4-mmap-prepare-vma-flag-sanify-v4-26-a1f052500fd7@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Andrew Morton Reviewed-by: Zi Yan Acked-by: David Hildenbrand (Arm) Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Pedro Falcato Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Michal Hocko Cc: Jonathan Corbet Cc: Greg Kroah-Hartman Cc: Dennis Dalessandro Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Paul Moore Cc: Stephen Smalley Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Andrii Nakryiko Cc: Eduard Zingerman Cc: Kumar Kartikeya Dwivedi Cc: Baolin Wang Cc: Nico Pache Cc: Ryan Roberts Cc: Dev Jain Cc: Barry Song Cc: Lance Yang Cc: Usama Arif Cc: Kiryl Shutsemau Cc: Doug Gilbert Cc: James Bottomley Cc: Martin K. Petersen Cc: Simona Vetter Cc: Helge Deller Cc: Sebastian Reichel Cc: John Hubbard Cc: Peter Xu Cc: Masami Hiramatsu Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: Arnaldo Carvalho de Melo Cc: Namhyung Kim Cc: Mark Rutland Cc: Rik van Riel Cc: Harry Yoo Cc: Juri Lelli Cc: Vincent Guittot Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Will Deacon Cc: Aneesh Kumar K.V Cc: Nicholas Piggin Cc: Arnd Bergmann Cc: Muchun Song Cc: Oscar Salvador Cc: Matthew Wilcox (Oracle) Cc: Jan Kara Cc: Marc Zyngier Cc: Oliver Upton Cc: Catalin Marinas Cc: Madhavan Srinivasan Cc: Anup Patel Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: Christian Borntraeger Cc: Janosch Frank Cc: Claudio Imbrenda Cc: Alexander Gordeev Cc: Gerald Schaefer Cc: Heiko Carstens Cc: Vasily Gorbik Cc: David S. Miller Cc: Andreas Larsson Cc: Al Viro Cc: Christian Brauner Cc: Matthew Brost Cc: Joshua Hahn Cc: Rakie Kim Cc: Byungchul Park Cc: Gregory Price Cc: Ying Huang Cc: Alistair Popple Cc: Chris Li Cc: Kairui Song Cc: Kemeng Shi Cc: Nhat Pham Cc: Baoquan He Cc: Youngjun Park Cc: Johannes Weiner Cc: Qi Zheng Cc: Shakeel Butt Cc: Axel Rasmussen Cc: Yuanchu Xie Cc: Wei Xu Cc: Chengming Zhou Cc: Michal Hocko Cc: Miklos Szeredi Cc: Xu Xin

mm: userland pgtable freeing is RCU-safe now, remove leftover bits

2026-10-05T06:35:39+00:00

Now every architecture has been converted to support CONFIG_MMU_GATHER_RCU_TABLE_FREE, this configuration option no longer makes any sense to keep around. Therefore remove it, and remove all the dead code that existed for !CONFIG_MMU_GATHER_RCU_TABLE_FREE architectures previously. Additionally, CONFIG_MMU_GATHER_TABLE_FREE is no longer necessary, as all architectures instead use CONFIG_HAVE_ARCH_TLB_REMOVE_TABLE when a custom __tlb_remove_table() is required, so remove this too. A number of architectures only enabled CONFIG_MMU_GATHER_RCU_TABLE_FREE if CONFIG_MMU was set, however the mmu_gather logic only actually does something meaningful if CONFIG_MMU is set (mmu_gather.c is only compiled in this case, for instance). As a result, there's no need to gate any of this logic on CONFIG_MMU explicitly. CONFIG_PT_RECLAIM however does have a strict dependency on CONFIG_MMU, so make this dependency explicit. Additionally, correct comments to remove references to non-RCU page table gathering and make it clear that this is not 'semi-RCU', nor has it been since commit 1fb3d8c20bfa ("mm/mmu_gather: replace IPI with synchronize_rcu() when batch allocation fails"). With this change in place the kernel policy is now that userspace page tables are freed after an RCU grace period, and thus it is now safe to unconditionally perform page table walks under RCU, safe in the knowledge that page tables will not be freed underneath the walker. This is all that is guaranteed, however, so naturally it is still incumbent upon page table walkers to ensure that the page table entries are as expected. Link: https://lore.kernel.org/20260925-rcu-pagetable-freeing-v5-11-31e91065fea4@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Andrew Morton Acked-by: Kiryl Shutsemau (Meta) Reviewed-by: Lance Yang Acked-by: David Hildenbrand (Arm) Cc: Zi Yan Cc: Baolin Wang Cc: Liam R. Howlett Cc: Nico Pache Cc: Ryan Roberts Cc: Dev Jain Cc: Barry Song Cc: Usama Arif Cc: Guo Ren Cc: Brian Cain Cc: Geert Uytterhoeven Cc: Dinh Nguyen Cc: Simon Schuster Cc: Jonas Bonn Cc: Stefan Kristiansson Cc: Stafford Horne Cc: Rich Felker Cc: John Paul Adrian Glaubitz Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: Alexandre Ghiti Cc: Russell King Cc: Vineet Gupta Cc: Michal Simek Cc: Chris Zankel Cc: Max Filippov Cc: Will Deacon Cc: Aneesh Kumar K.V Cc: Nicholas Piggin Cc: Peter Zijlstra Cc: David S. Miller Cc: Andreas Larsson Cc: Richard Henderson Cc: Matt Turner Cc: Magnus Lindholm Cc: Catalin Marinas Cc: Mark Rutland Cc: Huacai Chen Cc: WANG Xuerui Cc: Thomas Bogendoerfer Cc: James Bottomley Cc: Helge Deller Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Christophe Leroy Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Alexander Gordeev Cc: Christian Borntraeger Cc: Sven Schnelle Cc: Richard Weinberger Cc: Anton Ivanov Cc: Johannes Berg Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: H. Peter Anvin Cc: Arnd Bergmann Cc: Vlastimil Babka Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Michal Hocko Cc: Jason Gunthorpe Cc: John Hubbard Cc: Peter Xu Cc: Yoshinori Sato Cc: Shakeel Butt Cc: Jonathan Corbet Cc: Randy Dunlap Cc: Hugh Dickins Cc: Qi Zheng

mm: drop pxd_ERROR()

2026-10-05T06:34:55+00:00

There are no more users left for any pxd_ERROR() either in generic MM or in the platform MM. Hence all these platform macros along with their generic fallback could be dropped across the tree. Link: https://lore.kernel.org/20260831054331.625505-9-anshuman.khandual@arm.com Signed-off-by: Anshuman Khandual Signed-off-by: Andrew Morton Acked-by: Geert Uytterhoeven # m68k Acked-by: David Hildenbrand (Arm) Acked-by: Mike Rapoport (Microsoft) Cc: Helge Deller Cc: Huacai Chen Cc: James Bottomley Cc: John Paul Adrian Glaubitz Cc: Lorenzo Stoakes Cc: Rich Felker Cc: Samuel Holland Cc: WANG Xuerui Cc: Yoshinori Sato

kbuild: keep .modinfo when vmlinux is linked with --gc-sections

2026-09-27T18:35:12+00:00

Builds with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y, such as arm allmodconfig, now fail while extracting modules.builtin.modinfo: arm-linux-gnueabihf-objcopy: vmlinux.unstripped: can't dump section '.modinfo' - it does not exist: file format not recognized /bin/sh: 1: cannot open modules.builtin.modinfo: No such file or, with LLVM: llvm-objcopy: error: 'vmlinux.unstripped': section '.modinfo' not found Nothing references the MODULE_INFO() strings, so --gc-sections discards every .modinfo input section and vmlinux.unstripped ends up with no .modinfo data. This is not new: ever since modules.builtin.modinfo started being extracted from vmlinux.unstripped, these builds have silently produced an empty file, losing the modinfo of every built-in module. An arm multi_v7_defconfig build with LD_DEAD_CODE_DATA_ELIMINATION on current mainline yields a 0 byte modules.builtin.modinfo. The switch to --dump-section only turned that into a build error. Wrap the input section in KEEP() so that the linker retains it. The output section is still (INFO), so nothing is allocated for it. With the same arm config, modules.builtin.modinfo now has 14119 entries, and on x86_64 defconfig, where nothing is garbage collected, it is byte-identical before and after this change. Found by KernelCI builds of the linus-next tree. Fixes: 39cfd5b12160 ("kbuild: extract modules.builtin.modinfo from vmlinux.unstripped") Fixes: 5fe4dd596641 ("kbuild: do not allocate .modinfo in vmlinux") Assisted-by: LLM Signed-off-by: Sasha Levin Link: https://patch.msgid.link/20260927161227.1179863-1-sashal@kernel.org Signed-off-by: Nathan Chancellor

kbuild: do not allocate .modinfo in vmlinux

2026-09-25T23:16:33+00:00

Commit 3e86e4d74c04 ("kbuild: keep .modinfo section in vmlinux.unstripped") placed MODULE_INFO() strings in the .modinfo section in vmlinux.unstripped, however it left the section allocatable, so it gets assigned an address and on arm64, arm and riscv, the section is tagged as PT_LOAD. This is useless as the data is ultimately stripped anyway. Doing this results in a lot of unnecessary work - each pass copies the whole file, 450 MiB with relocations for an x86 allmodconfig build and 250 MiB for an arm64 allmodconfig build. This adds ~0.7s on the serial tail of every build for arm64 and ~0.2s for x86 (the tail is single-threaded work done after parallel work has finished). Nothing requires .modinfo to exist at an address, so mark the output section (INFO) so that it's not allocated and use --dump-section to extract it as -O only emits allocated sections. The dump doesn't pick up the arch's OBJCOPYFLAGS any longer as they should not impact the output of this section. Image, bzImage, System.map and modules.builtin.modinfo are unchanged and the stripped vmlinux differs only in its program headers. The objcopy passes are on the serial tail of every build that links vmlinux, no-op builds are unchanged. Whole build, 128-thread Threadripper 9980X, best of N runs: before after delta ------------------------------- x86 defconfig, touch mm/vma.c, gcc 11.2s 11.1s -0.15s (-1%) x86 defconfig, touch mm/vma.c, clang 11.3s 11.1s -0.19s (-2%) x86 defconfig, clean, gcc 32.5s 32.3s -0.16s (-1%) x86 defconfig, clean, clang 34.5s 34.2s -0.26s (-1%) x86 allmodconfig, touch mm/vma.c, gcc 40.1s 39.7s -0.44s (-1%) Assisted-by: LLM Reviewed-by: Kees Cook Signed-off-by: Lorenzo Stoakes (ARM) Reviewed-by: Nicolas Schier Link: https://patch.msgid.link/20260923-build-speedup-v4-1-73128809a4a4@kernel.org Signed-off-by: Nathan Chancellor

kho: rename KHO scratch to KHO bootmem

2026-09-24T08:09:35+00:00

The term "KHO scratch" is vague and overloaded. For one, it does not accurately describe what the memory is for. From KHO's perspective, it is memory passed by the previous kernel that is guaranteed to have no allocations and hence it is safe to allocate from. For another, the term is overloaded. KHO also knows to discover other ranges of memory that don't have any preservations and are safe to allocate from. This is done by kho_extend_scratch(). These areas, while called "scratch", are completely different from the chunk of memory passed by the previous kernel for early boot allocations. Rename "KHO scratch" to "KHO boot memory", or "KHO bootmem" in short. Update all function names, variable names, comments, and documentation to use this. Call the discovered areas "noprsrv", matching what memblock would see them as. Rename kho_extend_scratch() to reflect this. This patch largely has no functional changes. The only functional changes are renames of debugfs files from "scratch_phys" and "scratch_len" to "bootmem_phys" and "bootmem_len" respectively. Signed-off-by: Pratyush Yadav (Google) Link: https://patch.msgid.link/20260922041321.233986-4-pratyush@kernel.org Signed-off-by: Mike Rapoport (Microsoft)