kernel/git/next/linux-next.git/mm/Kconfig.debug, branch master

mm: move alloc tag to mm

2026-07-10T03:14:44+00:00

The alloc tagging work is really mm-specific, so move alloc_tag.c to mm/ and additionally update the MAINTAINERS entry to place it within memory management and port over the Kconfig and Makefile code to mm. Link: https://lore.kernel.org/20260625184857.2193482-3-surenb@google.com Signed-off-by: Lorenzo Stoakes Signed-off-by: Suren Baghdasaryan Reviewed-by: SeongJae Park Tested-by: Hao Ge Acked-by: Hao Ge Acked-by: Vlastimil Babka (SUSE) Acked-by: David Hildenbrand (Arm) Acked-by: Mike Rapoport (Microsoft) Acked-by: Harry Yoo (Oracle) Reviewed-by: Lorenzo Stoakes Cc: Brendan Jackman Cc: Kent Overstreet Cc: Liam R. Howlett Signed-off-by: Andrew Morton

mm: kmemleak: add CONFIG_DEBUG_KMEMLEAK_VERBOSE build option

2026-04-18T07:10:48+00:00

Add a Kconfig option to default kmemleak verbose mode on at build time. This option depends on DEBUG_KMEMLEAK_AUTO_SCAN since verbose reporting is only meaningful when the automatic scanning thread is running. When enabled, kmemleak prints full details (backtrace, hex dump, address) of unreferenced objects to dmesg as they are detected during scanning, removing the need to manually read /sys/kernel/debug/kmemleak. Making this a compile-time option rather than a boot parameter allows debug kernel flavors to enable verbose kmemleak reporting by default without requiring changes to boot arguments. A machine can simply swap to a debug kernel and benefit from kmemleak reporting automatically. By surfacing leak reports directly in dmesg, they are automatically forwarded through any kernel logging infrastructure and can be easily captured by log aggregation tooling, making it practical to monitor memory leaks across large fleets. The verbose setting can still be toggled at runtime via /sys/module/kmemleak/parameters/verbose. Link: https://lore.kernel.org/20260323-kmemleak_report-v1-1-ba2cdd9c11b9@debian.org Signed-off-by: Breno Leitao Acked-by: SeongJae Park Acked-by: Vlastimil Babka (SUSE) Reviewed-by: Lorenzo Stoakes (Oracle) Acked-by: Catalin Marinas Cc: David Hildenbrand Cc: Liam Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Signed-off-by: Andrew Morton

mm: fix DEBUG_RODATA_TEST indentation in Kconfig

2025-11-29T18:41:09+00:00

Most of the DEBUG_RODATA_TEST section is indented by four spaces instead of the customary single TAB. Link: https://lkml.kernel.org/r/74f39b1bffc6ed802088cb3e7d17b4c82330e8b3.1764058676.git.geert@linux-m68k.org Fixes: 2959a5f726f6 ("mm: add arch-independent testcases for RODATA") Signed-off-by: Geert Uytterhoeven Reviewed-by: Mike Rapoport (Microsoft) Reviewed-by: Anshuman Khandual Cc: Jinbum Park Cc: Kees Cook Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton

mm: rename GENERIC_PTDUMP and PTDUMP_CORE

2025-03-17T07:05:32+00:00

Platforms subscribe into generic ptdump implementation via GENERIC_PTDUMP. But generic ptdump gets enabled via PTDUMP_CORE. These configs combination is confusing as they sound very similar and does not differentiate between platform's feature subscription and feature enablement for ptdump. Rename the configs as ARCH_HAS_PTDUMP and PTDUMP making it more clear and improve readability. Link: https://lkml.kernel.org/r/20250226122404.1927473-6-anshuman.khandual@arm.com Signed-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

mm: make DEBUG_WX depdendent on GENERIC_PTDUMP

2025-03-17T07:05:31+00:00

DEBUG_WX selects PTDUMP_CORE without even ensuring that the given platform implements GENERIC_PTDUMP. This problem has been latent until now, as all the platforms subscribing ARCH_HAS_DEBUG_WX also subscribe GENERIC_PTDUMP. Link: https://lkml.kernel.org/r/20250226122404.1927473-5-anshuman.khandual@arm.com Signed-off-by: Anshuman Khandual Reviewed-by: Steven Price Reviewed-by: Christophe Leroy Cc: Catalin Marinas Cc: Heiko Carstens Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Madhavan Srinivasan Cc: Marc Zyngier Cc: Mark Rutland Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Will Deacon Signed-off-by: Andrew Morton

slub: Introduce CONFIG_SLUB_RCU_DEBUG

2024-08-27T12:12:51+00:00

Currently, KASAN is unable to catch use-after-free in SLAB_TYPESAFE_BY_RCU slabs because use-after-free is allowed within the RCU grace period by design. Add a SLUB debugging feature which RCU-delays every individual kmem_cache_free() before either actually freeing the object or handing it off to KASAN, and change KASAN to poison freed objects as normal when this option is enabled. For now I've configured Kconfig.debug to default-enable this feature in the KASAN GENERIC and SW_TAGS modes; I'm not enabling it by default in HW_TAGS mode because I'm not sure if it might have unwanted performance degradation effects there. Note that this is mostly useful with KASAN in the quarantine-based GENERIC mode; SLAB_TYPESAFE_BY_RCU slabs are basically always also slabs with a ->ctor, and KASAN's assign_tag() currently has to assign fixed tags for those, reducing the effectiveness of SW_TAGS/HW_TAGS mode. (A possible future extension of this work would be to also let SLUB call the ->ctor() on every allocation instead of only when the slab page is allocated; then tag-based modes would be able to assign new tags on every reallocation.) Tested-by: syzbot+263726e59eab6b442723@syzkaller.appspotmail.com Reviewed-by: Andrey Konovalov Acked-by: Marco Elver Acked-by: Vlastimil Babka #slab Signed-off-by: Jann Horn Signed-off-by: Vlastimil Babka

mm/slub: unify all sl[au]b parameters with "slab_$param"

2024-01-22T09:31:08+00:00

Since the SLAB allocator has been removed, so we can clean up the sl[au]b_$params. With only one slab allocator left, it's better to use the generic "slab" term instead of "slub" which is an implementation detail, which is pointed out by Vlastimil Babka. For more information please see [1]. Hence, we are going to use "slab_$param" as the primary prefix. This patch is changing the following slab parameters - slub_max_order - slub_min_order - slub_min_objects - slub_debug to - slab_max_order - slab_min_order - slab_min_objects - slab_debug as the primary slab parameters for all references of them in docs and comments. But this patch won't change variables and functions inside slub as we will have wider slub/slab change. Meanwhile, "slub_$params" can also be passed by command line, which is to keep backward compatibility. Also mark all "slub_$params" as legacy. Remove the separate descriptions for slub_[no]merge, append legacy tip for them at the end of descriptions of slab_[no]merge. [1] https://lore.kernel.org/linux-mm/7512b350-4317-21a0-fab3-4101bc4d8f7a@suse.cz/ Signed-off-by: Xiongwei Song Reviewed-by: Vlastimil Babka Signed-off-by: Vlastimil Babka

mm/slab: remove CONFIG_SLAB from all Kconfig and Makefile

2023-12-05T10:14:40+00:00

Remove CONFIG_SLAB, CONFIG_DEBUG_SLAB, CONFIG_SLAB_DEPRECATED and everything in Kconfig files and mm/Makefile that depends on those. Since SLUB is the only remaining allocator, remove the allocator choice, make CONFIG_SLUB a "def_bool y" for now and remove all explicit dependencies on SLUB or SLAB as it's now always enabled. Make every option's verbose name and description refer to "the slab allocator" without refering to the specific implementation. Do not rename the CONFIG_ option names yet. Everything under #ifdef CONFIG_SLAB, and mm/slab.c is now dead code, all code 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

mm: page_table_check: Make it dependent on EXCLUSIVE_SYSTEM_RAM

2023-05-29T15:14:28+00:00

Without EXCLUSIVE_SYSTEM_RAM, users are allowed to map arbitrary physical memory regions into the userspace via /dev/mem. At the same time, pages may change their properties (e.g., from anonymous pages to named pages) while they are still being mapped in the userspace, leading to "corruption" detected by the page table check. To avoid these false positives, this patch makes PAGE_TABLE_CHECK depends on EXCLUSIVE_SYSTEM_RAM. This dependency is understandable because PAGE_TABLE_CHECK is a hardening technique but /dev/mem without STRICT_DEVMEM (i.e., !EXCLUSIVE_SYSTEM_RAM) is itself a security problem. Even with EXCLUSIVE_SYSTEM_RAM, I/O pages may be still allowed to be mapped via /dev/mem. However, these pages are always considered as named pages, so they won't break the logic used in the page table check. Cc: # 5.17 Signed-off-by: Ruihan Li Acked-by: David Hildenbrand Acked-by: Pasha Tatashin Link: https://lore.kernel.org/r/20230515130958.32471-4-lrh2000@pku.edu.cn Signed-off-by: Greg Kroah-Hartman

mm: change per-VMA lock statistics to be disabled by default

2023-05-03T00:23:28+00:00

Change CONFIG_PER_VMA_LOCK_STATS to be disabled by default, as most users don't need it. Add configuration help to clarify its usage. Link: https://lkml.kernel.org/r/20230428173533.18158-1-surenb@google.com Fixes: 52f238653e45 ("mm: introduce per-VMA lock statistics") Signed-off-by: Suren Baghdasaryan Suggested-by: Linus Torvalds Reviewed-by: Lorenzo Stoakes Acked-by: Vlastimil Babka Reviewed-by: David Hildenbrand Signed-off-by: Andrew Morton