Changes in Makefile

f9aad622 - mm: rename GENERIC_PTDUMP and PTDUMP_CORE

Wed, 26 Feb 2025 12:24:04 +0000

mm: rename GENERIC_PTDUMP and PTDUMP_COREPlatforms subscribe into generic ptdump implementation via GENERIC_PTDUMP.But generic ptdump gets enabled via PTDUMP_CORE. These configscombination is confusing as they sound very similar and does notdifferentiate between platform's feature subscription and featureenablement for ptdump. Rename the configs as ARCH_HAS_PTDUMP and PTDUMPmaking it more clear and improve readability.Link: https://lkml.kernel.org/r/20250226122404.1927473-6-anshuman.khandual@arm.comSigned-off-by: Anshuman Khandual Reviewed-by: Christophe Leroy (powerpc)Acked-by: Catalin Marinas [arm64]Cc: Will Deacon Cc: Jonathan Corbet Cc: Marc Zyngier Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Christophe Leroy Cc: Madhavan Srinivasan Cc: Mark Rutland Cc: Steven Price Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Makefile

0ff67f99 - mm, swap: remove swap slot cache

Thu, 13 Mar 2025 16:59:34 +0000

mm, swap: remove swap slot cacheSlot cache is no longer needed now, removing it and all related code.- vm-scalability with: `usemem --init-time -O -y -x -R -31 1G`,12G memory cgroup using simulated pmem as SWAP (32G pmem, 32 CPUs),16 test runs for each case, measuring the total throughput: Before (KB/s) (stdev) After (KB/s) (stdev)Random (4K): 424907.60 (24410.78) 414745.92 (34554.78)Random (64K): 163308.82 (11635.72) 167314.50 (18434.99)Sequential (4K, !-R): 6150056.79 (103205.90) 6321469.06 (115878.16)The performance changes are below noise level.- Build linux kernel with make -j96, using 4K folio with 1.5G memorycgroup limit and 64K folio with 2G memory cgroup limit, on top of tmpfs,12 test runs, measuring the system time: Before (s) (stdev) After (s) (stdev)make -j96 (4K): 6445.69 (61.95) 6408.80 (69.46)make -j96 (64K): 6841.71 (409.04) 6437.99 (435.55)Similar to above, 64k mTHP case showed a slight improvement.Link: https://lkml.kernel.org/r/20250313165935.63303-7-ryncsn@gmail.comSigned-off-by: Kairui Song Reviewed-by: Baoquan He Cc: Baolin Wang Cc: Barry Song Cc: Chris Li Cc: "Huang, Ying" Cc: Hugh Dickins Cc: Johannes Weiner Cc: Kalesh Singh Cc: Matthew Wilcow (Oracle) Cc: Nhat Pham Cc: Yosry Ahmed Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Makefile

474fe91f - mm/hugetlb: move hugetlb CMA code in to its own file

Fri, 28 Feb 2025 18:29:28 +0000

mm/hugetlb: move hugetlb CMA code in to its own filehugetlb.c contained a number of CONFIG_CMA ifdefs, and the code insidethem was large enough to merit being in its own file, so move it, cleaningup things a bit.Hide some direct variable access behind functions to accommodate the move.No functional change intended.Link: https://lkml.kernel.org/r/20250228182928.2645936-28-fvdl@google.comSigned-off-by: Frank van der Linden Cc: Alexander Gordeev Cc: Andy Lutomirski Cc: Arnd Bergmann Cc: Dan Carpenter Cc: Dave Hansen Cc: David Hildenbrand Cc: Heiko Carstens Cc: Joao Martins Cc: Johannes Weiner Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Muchun Song Cc: Oscar Salvador Cc: Peter Zijlstra Cc: Roman Gushchin (Cruise) Cc: Usama Arif Cc: Vasily Gorbik Cc: Yu Zhao Cc: Zi Yan Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Makefile

6df8bae8 - mm: zbud: remove zbud

Wed, 29 Jan 2025 18:06:32 +0000

mm: zbud: remove zbudThe zbud compressed pages allocator is rarely used, most users usezsmalloc. zbud consumes much more memory (only stores 1 or 2 compressedpages per physical page). The only advantage of zbud is a marginalperformance improvement that by no means justify the memory overhead.Historically, zsmalloc had significantly worse latency than zbud andz3fold but offered better memory savings. This is no longer the case asshown by a simple recent analysis [1]. In a kernel build test on tmpfs ina limited cgroup, zbud 2-3% less time than zsmalloc, but at the cost ofusing ~32% more memory (1.5G vs 1.13G). The tradeoff does not make sensefor zbud in any practical scenario.The only alleged advantage of zbud is not having the dependency onCONFIG_MMU, but CONFIG_SWAP already depends on CONFIG_MMU anyway, and zbudis only used by zswap.Remove zbud after z3fold's removal, leaving zsmalloc as the one and onlyzpool allocator. Leave the removal of the zpool API (and its associatedconfig options) to a followup cleanup after no more allocators show up.Deprecating zbud for a few cycles before removing it was initiallyproposed [2], like z3fold was marked as deprecated for 2 cycles [3]. However, Johannes rightfully pointed out that the 2 cycles is too shortfor most downstream consumers, and z3fold was deprecated first only as acourtesy anyway.[1]https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndqF+3+_Vg@mail.gmail.com/[2]https://lore.kernel.org/lkml/Z5gdnSX5Lv-nfjQL@google.com/[3]https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed@google.com/Link: https://lkml.kernel.org/r/20250129180633.3501650-3-yosry.ahmed@linux.devSigned-off-by: Yosry Ahmed Reviewed-by: Shakeel Butt Acked-by: Johannes Weiner Acked-by: Nhat Pham Cc: Alexander Gordeev Cc: Chengming Zhou Cc: Christian Borntraeger Cc: Dan Streetman Cc: Heiko Carstens Cc: Huacai Chen Cc: Miaohe Lin Cc: Seth Jennings Cc: Sven Schnelle Cc: Vasily Gorbik Cc: Vitaly Wool Cc: Vlastimil Babka Cc: WANG Xuerui Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Makefile

58ba73e5 - mm: z3fold: remove z3fold

Wed, 29 Jan 2025 18:06:31 +0000

mm: z3fold: remove z3foldPatch series "mm: zswap: remove z3fold and zbud", v2.After 2 cycles of deprecating z3fold, remove it as well as zbud (rationalein specific patches).This patch (of 2):Z3fold has been marked as deprecated for 2 cycles and no one complained,as expected. As there are no known users, remove the code now.Link: https://lkml.kernel.org/r/20250129180633.3501650-1-yosry.ahmed@linux.devLink: https://lkml.kernel.org/r/20250129180633.3501650-2-yosry.ahmed@linux.devSigned-off-by: Yosry Ahmed Acked-by: Johannes Weiner Reviewed-by: Shakeel Butt Acked-by: Nhat Pham Cc: Alexander Gordeev Cc: Chengming Zhou Cc: Christian Borntraeger Cc: Dan Streetman Cc: Heiko Carstens Cc: Huacai Chen Cc: Miaohe Lin Cc: Seth Jennings Cc: Sven Schnelle Cc: Vasily Gorbik Cc: Vitaly Wool Cc: Vlastimil Babka Cc: WANG Xuerui Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Makefile

6375e95f - mm: pgtable: reclaim empty PTE page in madvise(MADV_DONTNEED)

Wed, 04 Dec 2024 11:09:49 +0000

mm: pgtable: reclaim empty PTE page in madvise(MADV_DONTNEED)Now in order to pursue high performance, applications mostly use somehigh-performance user-mode memory allocators, such as jemalloc ortcmalloc. These memory allocators use madvise(MADV_DONTNEED or MADV_FREE)to release physical memory, but neither MADV_DONTNEED nor MADV_FREE willrelease page table memory, which may cause huge page table memory usage.The following are a memory usage snapshot of one process which actuallyhappened on our server: VIRT: 55t RES: 590g VmPTE: 110gIn this case, most of the page table entries are empty. For such a PTEpage where all entries are empty, we can actually free it back to thesystem for others to use.As a first step, this commit aims to synchronously free the empty PTEpages in madvise(MADV_DONTNEED) case. We will detect and free empty PTEpages in zap_pte_range(), and will add zap_details.reclaim_pt to excludecases other than madvise(MADV_DONTNEED).Once an empty PTE is detected, we first try to hold the pmd lock withinthe pte lock. If successful, we clear the pmd entry directly (fast path).Otherwise, we wait until the pte lock is released, then re-hold the pmdand pte locks and loop PTRS_PER_PTE times to check pte_none() to re-detectwhether the PTE page is empty and free it (slow path).For other cases such as madvise(MADV_FREE), consider scanning and freeingempty PTE pages asynchronously in the future.The following code snippet can show the effect of optimization: mmap 50G while (1) { for (; i < 1024 * 25; i++) { touch 2M memory madvise MADV_DONTNEED 2M } }As we can see, the memory usage of VmPTE is reduced: before afterVIRT 50.0 GB 50.0 GBRES 3.1 MB 3.1 MBVmPTE 102640 KB 240 KB[zhengqi.arch@bytedance.com: fix uninitialized symbol 'ptl'] Link: https://lkml.kernel.org/r/20241206112348.51570-1-zhengqi.arch@bytedance.com Link: https://lore.kernel.org/linux-mm/224e6a4e-43b5-4080-bdd8-b0a6fb2f0853@stanley.mountain/Link: https://lkml.kernel.org/r/92aba2b319a734913f18ba41e7d86a265f0b84e2.1733305182.git.zhengqi.arch@bytedance.comSigned-off-by: Qi Zheng Cc: Andy Lutomirski Cc: Catalin Marinas Cc: Dave Hansen Cc: David Hildenbrand Cc: David Rientjes Cc: Hugh Dickins Cc: Jann Horn Cc: Lorenzo Stoakes Cc: Matthew Wilcox Cc: Mel Gorman Cc: Muchun Song Cc: Peter Xu Cc: Peter Zijlstra Cc: Will Deacon Cc: Zach O'Keefe Cc: Dan Carpenter Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Makefile

65941f10 - mm: move the page fragment allocator from page_alloc into its own file

Mon, 28 Oct 2024 11:53:37 +0000

mm: move the page fragment allocator from page_alloc into its own fileInspired by [1], move the page fragment allocator from page_allocinto its own c file and header file, as we are about to make morechange for it to replace another page_frag implementation insock.cAs this patchset is going to replace 'struct page_frag' with'struct page_frag_cache' in sched.h, including page_frag_cache.hin sched.h has a compiler error caused by interdependence betweenmm_types.h and mm.h for asm-offsets.c, see [2]. So avoid the compilererror by moving 'struct page_frag_cache' to mm_types_task.h assuggested by Alexander, see [3].1. https://lore.kernel.org/all/20230411160902.4134381-3-dhowells@redhat.com/2. https://lore.kernel.org/all/15623dac-9358-4597-b3ee-3694a5956920@gmail.com/3. https://lore.kernel.org/all/CAKgT0UdH1yD=LSCXFJ=YM_aiA4OomD-2wXykO42bizaWMt_HOA@mail.gmail.com/CC: David Howells CC: Linux-MM Signed-off-by: Yunsheng Lin Acked-by: Andrew Morton Reviewed-by: Alexander Duyck Link: https://patch.msgid.link/20241028115343.3405838-3-linyunsheng@huawei.comSigned-off-by: Jakub Kicinski List of files: /linux-6.15/mm/Makefile

b0c4e27c - mm: introduce numa_emulation

Wed, 07 Aug 2024 06:41:03 +0000

mm: introduce numa_emulationMove numa_emulation code from arch/x86 to mm/numa_emulation.cThis code will be later reused by arch_numa.No functional changes.Link: https://lkml.kernel.org/r/20240807064110.1003856-20-rppt@kernel.orgSigned-off-by: Mike Rapoport (Microsoft) Tested-by: Zi Yan # for x86_64 and arm64Reviewed-by: Jonathan Cameron Tested-by: Jonathan Cameron [arm64 + CXL via QEMU]Acked-by: Dan Williams Cc: Alexander Gordeev Cc: Andreas Larsson Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Catalin Marinas Cc: Christophe Leroy Cc: Dave Hansen Cc: David Hildenbrand Cc: Davidlohr Bueso Cc: David S. Miller Cc: Greg Kroah-Hartman Cc: Heiko Carstens Cc: Huacai Chen Cc: Ingo Molnar Cc: Jiaxun Yang Cc: John Paul Adrian Glaubitz Cc: Jonathan Corbet Cc: Michael Ellerman Cc: Palmer Dabbelt Cc: Rafael J. Wysocki Cc: Rob Herring (Arm) Cc: Samuel Holland Cc: Thomas Bogendoerfer Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Will Deacon Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Makefile

87482708 - mm: introduce numa_memblks

Wed, 07 Aug 2024 06:41:01 +0000

mm: introduce numa_memblksMove code dealing with numa_memblks from arch/x86 to mm/ and add Kconfigoptions to let x86 select it in its Kconfig.This code will be later reused by arch_numa.No functional changes.Link: https://lkml.kernel.org/r/20240807064110.1003856-18-rppt@kernel.orgSigned-off-by: Mike Rapoport (Microsoft) Tested-by: Zi Yan # for x86_64 and arm64Reviewed-by: Jonathan Cameron Tested-by: Jonathan Cameron [arm64 + CXL via QEMU]Acked-by: Dan Williams Acked-by: David Hildenbrand Cc: Alexander Gordeev Cc: Andreas Larsson Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Catalin Marinas Cc: Christophe Leroy Cc: Dave Hansen Cc: Davidlohr Bueso Cc: David S. Miller Cc: Greg Kroah-Hartman Cc: Heiko Carstens Cc: Huacai Chen Cc: Ingo Molnar Cc: Jiaxun Yang Cc: John Paul Adrian Glaubitz Cc: Jonathan Corbet Cc: Michael Ellerman Cc: Palmer Dabbelt Cc: Rafael J. Wysocki Cc: Rob Herring (Arm) Cc: Samuel Holland Cc: Thomas Bogendoerfer Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Will Deacon Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Makefile

0e8b6798 - mm: move kernel/numa.c to mm/

Wed, 07 Aug 2024 06:40:45 +0000

mm: move kernel/numa.c to mm/Patch series "mm: introduce numa_memblks", v4.Following the discussion about handling of CXL fixed memory windows onarm64 [1] I decided to bite the bullet and move numa_memblks from x86 tothe generic code so they will be available on arm64/riscv and maybe onloongarch sometime later.While it could be possible to use memblock to describe CXL memory windows,it currently lacks notion of unpopulated memory ranges and numa_memblksdoes implement this.Another reason to make numa_memblks generic is that both arch_numa (arm64and riscv) and loongarch use trimmed copy of x86 code although there is nofundamental reason why the same code cannot be used on all theseplatforms. Having numa_memblks in mm/ will make it's interaction withACPI and FDT more consistent and I believe will reduce maintenance burden.And with generic numa_memblks it is (almost) straightforward to enableNUMA emulation on arm64 and riscv.The first 9 commits in this series are cleanups that are not strictlyrelated to numa_memblks.Commits 10-16 slightly reorder code in x86 to allow extracting numa_memblksand NUMA emulation to the generic code.Commits 17-19 actually move the code from arch/x86/ to mm/ and commits 20-22does some aftermath cleanups.Commit 23 updates of_numa_init() to return error of no NUMA nodes werefound in the device tree.Commit 24 switches arch_numa to numa_memblks.Commit 25 enables usage of phys_to_target_node() andmemory_add_physaddr_to_nid() with numa_memblks.Commit 26 moves the description for numa=fake from x86 to admin-guide.[1] https://lore.kernel.org/all/20240529171236.32002-1-Jonathan.Cameron@huawei.com/This patch (of 26):The stub functions in kernel/numa.c belong to mm/ rather than to kernel/Link: https://lkml.kernel.org/r/20240807064110.1003856-1-rppt@kernel.orgLink: https://lkml.kernel.org/r/20240807064110.1003856-2-rppt@kernel.orgSigned-off-by: Mike Rapoport (Microsoft) Acked-by: David Hildenbrand Reviewed-by: Jonathan Cameron Tested-by: Zi Yan # for x86_64 and arm64Tested-by: Jonathan Cameron [arm64 + CXL via QEMU]Acked-by: Dan Williams Cc: Alexander Gordeev Cc: Andreas Larsson Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Catalin Marinas Cc: Christophe Leroy Cc: Dave Hansen Cc: Davidlohr Bueso Cc: David S. Miller Cc: Greg Kroah-Hartman Cc: Heiko Carstens Cc: Huacai Chen Cc: Ingo Molnar Cc: Jiaxun Yang Cc: John Paul Adrian Glaubitz Cc: Jonathan Corbet Cc: Michael Ellerman Cc: Palmer Dabbelt Cc: Rafael J. Wysocki Cc: Rob Herring (Arm) Cc: Samuel Holland Cc: Thomas Bogendoerfer Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Will Deacon Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Makefile

49b1b8d6 - mm: move internal core VMA manipulation functions to own file

Mon, 29 Jul 2024 11:50:38 +0000

mm: move internal core VMA manipulation functions to own fileThis patch introduces vma.c and moves internal core VMA manipulationfunctions to this file from mmap.c.This allows us to isolate VMA functionality in a single place such that wecan create userspace testing code that invokes this functionality in anenvironment where we can implement simple unit tests of corefunctionality.This patch ensures that core VMA functionality is explicitly marked assuch by its presence in mm/vma.h.It also places the header includes required by vma.c in vma_internal.h,which is simply imported by vma.c. This makes the VMA functionalitytestable, as userland testing code can simply stub out functionality asrequired.Link: https://lkml.kernel.org/r/c77a6aafb4c42aaadb8e7271a853658cbdca2e22.1722251717.git.lorenzo.stoakes@oracle.comSigned-off-by: Lorenzo Stoakes Reviewed-by: Vlastimil Babka Reviewed-by: Liam R. Howlett Cc: Alexander Viro Cc: Brendan Higgins Cc: Christian Brauner Cc: David Gow Cc: Eric W. Biederman Cc: Jan Kara Cc: Kees Cook Cc: Matthew Wilcox (Oracle) Cc: Rae Moar Cc: SeongJae Park Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Pengfei Xu Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Makefile

9eace7e8 - shmem_quota: build the object file conditionally to the config option

Wed, 17 Jul 2024 06:37:27 +0000

shmem_quota: build the object file conditionally to the config optionInitially I added shmem-quota to obj-y, move it to the correct place andremove the unneeded full file #ifdefLink: https://lkml.kernel.org/r/20240717063737.910840-1-cem@kernel.orgSigned-off-by: Carlos Maiolino Suggested-by: Aristeu Rozanski Reviewed-by: Jan Kara Cc: Christian Brauner Cc: Hugh Dickins Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Makefile

e93d4166 - mm: memcg: put cgroup v1-specific code under a config option

Tue, 25 Jun 2024 00:59:05 +0000

mm: memcg: put cgroup v1-specific code under a config optionPut legacy cgroup v1 memory controller code under a new CONFIG_MEMCG_V1config option. The option is turned off by default. Nobody except thosewho are still using cgroup v1 should turn it on.If the option is not set, memory controller can still be mounted undercgroup v1, but none of memcg-specific control files are present.Please note, that not all cgroup v1's memory controller code is guardedyet (but most of it), it's a subject for some follow-up work.Thanks to Michal Hocko for providing a better Kconfig option description.[roman.gushchin@linux.dev: better config option description provided by Michal] Link: https://lkml.kernel.org/r/ZnxXNtvqllc9CDoo@google.comLink: https://lkml.kernel.org/r/20240625005906.106920-14-roman.gushchin@linux.devSigned-off-by: Roman Gushchin Acked-by: Michal Hocko Acked-by: Shakeel Butt Cc: Johannes Weiner Cc: Matthew Wilcox (Oracle) Cc: Muchun Song Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Makefile

1b1e1344 - mm: memcg: introduce memcontrol-v1.c

Tue, 25 Jun 2024 00:58:53 +0000

mm: memcg: introduce memcontrol-v1.cPatch series "mm: memcg: separate legacy cgroup v1 code and put underconfig option", v2.Cgroups v2 have been around for a while and many users have fully adoptedthem, so they never use cgroups v1 features and functionality. Yet theyhave to "pay" for the cgroup v1 support anyway:1) the kernel binary contains an unused cgroup v1 code,2) some code paths have additional checks which are not needed,3) some common structures like task_struct and mem_cgroup contain unused cgroup v1-specific members.Cgroup v1's memory controller has a number of features that are notsupported by cgroup v2 and their implementation is pretty much selfcontained. Most notably, these features are: soft limit reclaim, oomhandling in userspace, complicated event notification system, chargemigration. Cgroup v1-specific code in memcontrol.c is close to 4k linesin size and it's intervened with generic and cgroup v2-specific code. It's a burden on developers and maintainers.This patchset aims to solve these problems by:1) moving cgroup v1-specific memcg code to the new mm/memcontrol-v1.c file,2) putting definitions shared by memcontrol.c and memcontrol-v1.c into the mm/memcontrol-v1.h header,3) introducing the CONFIG_MEMCG_V1 config option, turned off by default,4) making memcontrol-v1.c to compile only if CONFIG_MEMCG_V1 is set.If CONFIG_MEMCG_V1 is not set, cgroup v1 memory controller is still availablefor mounting, however no memory-specific control knobs are present.This patch (of 14):This patch introduces the mm/memcontrol-v1.c source file which will beused for all legacy (cgroup v1) memory cgroup code. It also introducesmm/memcontrol-v1.h to keep declarations shared between mm/memcontrol.c andmm/memcontrol-v1.c.As of now, let's compile it if CONFIG_MEMCG is set, similar tomm/memcontrol.c. Later on it can be switched to use a separate configoption, so that the legacy code won't be compiled if not required.Link: https://lkml.kernel.org/r/20240625005906.106920-1-roman.gushchin@linux.devLink: https://lkml.kernel.org/r/20240625005906.106920-2-roman.gushchin@linux.devSigned-off-by: Roman Gushchin Acked-by: Michal Hocko Acked-by: Shakeel Butt Cc: Johannes Weiner Cc: Matthew Wilcox (Oracle) Cc: Muchun Song Cc: Roman Gushchin Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Makefile

8be7258a - mseal: add mseal syscall

Mon, 15 Apr 2024 16:35:21 +0000

mseal: add mseal syscallThe new mseal() is an syscall on 64 bit CPU, and with following signature:int mseal(void addr, size_t len, unsigned long flags)addr/len: memory range.flags: reserved.mseal() blocks following operations for the given memory range.1> Unmapping, moving to another location, and shrinking the size, via munmap() and mremap(), can leave an empty space, therefore can be replaced with a VMA with a new set of attributes.2> Moving or expanding a different VMA into the current location, via mremap().3> Modifying a VMA via mmap(MAP_FIXED).4> Size expansion, via mremap(), does not appear to pose any specific risks to sealed VMAs. It is included anyway because the use case is unclear. In any case, users can rely on merging to expand a sealed VMA.5> mprotect() and pkey_mprotect().6> Some destructive madvice() behaviors (e.g. MADV_DONTNEED) for anonymous memory, when users don't have write permission to the memory. Those behaviors can alter region contents by discarding pages, effectively a memset(0) for anonymous memory.Following input during RFC are incooperated into this patch:Jann Horn: raising awareness and providing valuable insights on thedestructive madvise operations.Linus Torvalds: assisting in defining system call signature and scope.Liam R. Howlett: perf optimization.Theo de Raadt: sharing the experiences and insight gained from implementing mimmutable() in OpenBSD.Finally, the idea that inspired this patch comes from Stephen Röttger'swork in Chrome V8 CFI.[jeffxu@chromium.org: add branch prediction hint, per Pedro] Link: https://lkml.kernel.org/r/20240423192825.1273679-2-jeffxu@chromium.orgLink: https://lkml.kernel.org/r/20240415163527.626541-3-jeffxu@chromium.orgSigned-off-by: Jeff Xu Reviewed-by: Kees Cook Reviewed-by: Liam R. Howlett Cc: Pedro Falcato Cc: Dave Hansen Cc: Greg Kroah-Hartman Cc: Guenter Roeck Cc: Jann Horn Cc: Jeff Xu Cc: Jonathan Corbet Cc: Jorge Lucangeli Obes Cc: Linus Torvalds Cc: Matthew Wilcox (Oracle) Cc: Muhammad Usama Anjum Cc: Pedro Falcato Cc: Stephen Röttger Cc: Suren Baghdasaryan Cc: Amer Al Shanawany Cc: Javier Carrasco Cc: Shuah Khan Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Makefile

12af2b83 - mm: introduce execmem_alloc() and execmem_free()

Sun, 05 May 2024 16:06:18 +0000

mm: introduce execmem_alloc() and execmem_free()module_alloc() is used everywhere as a mean to allocate memory for code.Beside being semantically wrong, this unnecessarily ties all subsystemsthat need to allocate code, such as ftrace, kprobes and BPF to modules andputs the burden of code allocation to the modules code.Several architectures override module_alloc() because of variousconstraints where the executable memory can be located and this causesadditional obstacles for improvements of code allocation.Start splitting code allocation from modules by introducing execmem_alloc()and execmem_free() APIs.Initially, execmem_alloc() is a wrapper for module_alloc() andexecmem_free() is a replacement of module_memfree() to allow updating allcall sites to use the new APIs.Since architectures define different restrictions on placement,permissions, alignment and other parameters for memory that can be used bydifferent subsystems that allocate executable memory, execmem_alloc() takesa type argument, that will be used to identify the calling subsystem and toallow architectures define parameters for ranges suitable for thatsubsystem.No functional changes.Signed-off-by: Mike Rapoport (IBM) Acked-by: Masami Hiramatsu (Google) Acked-by: Song Liu Acked-by: Steven Rostedt (Google) Signed-off-by: Luis Chamberlain List of files: /linux-6.15/mm/Makefile

c8d36bc2 - mm/kmemleak: disable KASAN instrumentation in kmemleak

Thu, 07 Mar 2024 19:05:48 +0000

mm/kmemleak: disable KASAN instrumentation in kmemleakKmemleak ia a memory leak checker. KASAN is also a memory checker but itfocuses more on finding out-of-bounds and use-after-free bugs. Sincekmemleak is inherently slow especially on systems with large number ofCPUs, adding KASAN instrumentation will make it slower even more. Askmemleak is not for production use, the utility of enabling KASAN there isquestionable.This patch disables KASAN instrumentation for configurations that enableboth of them to slightly reduce performance overhead.Link: https://lkml.kernel.org/r/20240307190548.963626-3-longman@redhat.comSigned-off-by: Waiman Long Acked-by: Catalin Marinas Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Makefile

c40845e3 - kbuild: make -Woverride-init warnings more consistent

Tue, 26 Mar 2024 14:47:16 +0000

kbuild: make -Woverride-init warnings more consistentThe -Woverride-init warn about code that may be intentional or not,but the inintentional ones tend to be real bugs, so there is a bit ofdisagreement on whether this warning option should be enabled by defaultand we have multiple settings in scripts/Makefile.extrawarn as well asindividual subsystems.Older versions of clang only supported -Wno-initializer-overrides withthe same meaning as gcc's -Woverride-init, though all supported versionsnow work with both. Because of this difference, an earlier cleanup ofmine accidentally turned the clang warning off for W=1 builds and onlyleft it on for W=2, while it's still enabled for gcc with W=1.There is also one driver that only turns the warning off for newerversions of gcc but not other compilers, and some but not all theMakefiles still use a cc-disable-warning conditional that is nolonger needed with supported compilers here.Address all of the above by removing the special cases for clangand always turning the warning off unconditionally where it gotin the way, using the syntax that is supported by both compilers.Fixes: 2cd3271b7a31 ("kbuild: avoid duplicate warning options")Signed-off-by: Arnd Bergmann Acked-by: Hamza Mahfooz Acked-by: Jani Nikula Acked-by: Andrew Jeffery Signed-off-by: Jani Nikula Reviewed-by: Linus Walleij Signed-off-by: Masahiro Yamada List of files: /linux-6.15/mm/Makefile

2a19be61 - mm/slab: remove CONFIG_SLAB from all Kconfig and Makefile

Mon, 02 Oct 2023 13:43:03 +0000

mm/slab: remove CONFIG_SLAB from all Kconfig and MakefileRemove CONFIG_SLAB, CONFIG_DEBUG_SLAB, CONFIG_SLAB_DEPRECATED andeverything in Kconfig files and mm/Makefile that depends on those. SinceSLUB is the only remaining allocator, remove the allocator choice, makeCONFIG_SLUB a "def_bool y" for now and remove all explicit dependencieson SLUB or SLAB as it's now always enabled. Make every option's verbosename and description refer to "the slab allocator" without refering tothe specific implementation. Do not rename the CONFIG_ option names yet.Everything under #ifdef CONFIG_SLAB, and mm/slab.c is now dead code, allcode under #ifdef CONFIG_SLUB is now always compiled.Reviewed-by: Kees Cook Reviewed-by: Christoph Lameter Acked-by: David Rientjes Tested-by: David Rientjes Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>Tested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>Signed-off-by: Vlastimil Babka List of files: /linux-6.15/mm/Makefile

96f7b2b9 - mm: vmscan: move shrinker-related code into a separate file

Mon, 11 Sep 2023 09:25:15 +0000

mm: vmscan: move shrinker-related code into a separate fileThe mm/vmscan.c file is too large, so separate the shrinker-related codefrom it into a separate file. No functional changes.Link: https://lkml.kernel.org/r/20230911092517.64141-3-zhengqi.arch@bytedance.comSigned-off-by: Qi Zheng Reviewed-by: Muchun Song Cc: Christian Brauner Cc: Christian König Cc: Chuck Lever Cc: Daniel Vetter Cc: Daniel Vetter Cc: Darrick J. Wong Cc: Dave Chinner Cc: Greg Kroah-Hartman Cc: Joel Fernandes Cc: Kirill Tkhai Cc: Paul E. McKenney Cc: Roman Gushchin Cc: Sergey Senozhatsky Cc: Steven Price Cc: Theodore Ts'o Cc: Vlastimil Babka Cc: Abhinav Kumar Cc: Alasdair Kergon Cc: Alexander Viro Cc: Alyssa Rosenzweig Cc: Andreas Dilger Cc: Andreas Gruenbacher Cc: Anna Schumaker Cc: Arnd Bergmann Cc: Bob Peterson Cc: Borislav Petkov Cc: Carlos Llamas Cc: Chandan Babu R Cc: Chao Yu Cc: Chris Mason Cc: Coly Li Cc: Dai Ngo Cc: Dave Hansen Cc: David Airlie Cc: David Hildenbrand Cc: David Sterba Cc: Dmitry Baryshkov Cc: Gao Xiang Cc: Huang Rui Cc: Ingo Molnar Cc: Jaegeuk Kim Cc: Jani Nikula Cc: Jan Kara Cc: Jason Wang Cc: Jeff Layton Cc: Jeffle Xu Cc: Joonas Lahtinen Cc: Josef Bacik Cc: Juergen Gross Cc: Kent Overstreet Cc: Marijn Suijten Cc: "Michael S. Tsirkin" Cc: Mike Snitzer Cc: Minchan Kim Cc: Muchun Song Cc: Nadav Amit Cc: Neil Brown Cc: Oleksandr Tyshchenko Cc: Olga Kornievskaia Cc: Richard Weinberger Cc: Rob Clark Cc: Rob Herring Cc: Rodrigo Vivi Cc: Sean Paul Cc: Song Liu Cc: Stefano Stabellini Cc: Thomas Gleixner Cc: Tomeu Vizoso Cc: Tom Talpey Cc: Trond Myklebust Cc: Tvrtko Ursulin Cc: Xuan Zhuo Cc: Yue Hu Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Makefile