mm: memcontrol: zap oom_info_lock

[cascardo/linux.git] / mm / Kconfig.debug

diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
index 957d3da..22f4cd9 100644 (file)
--- a/mm/Kconfig.debug
+++ b/mm/Kconfig.debug
@@ -16,8 +16,8 @@ config DEBUG_PAGEALLOC
        select PAGE_POISONING if !ARCH_SUPPORTS_DEBUG_PAGEALLOC
        ---help---
          Unmap pages from the kernel linear mapping after free_pages().
-         This results in a large slowdown, but helps to find certain types
-         of memory corruption.
+         Depending on runtime enablement, this results in a small or large
+         slowdown, but helps to find certain types of memory corruption.
 
          For architectures which don't enable ARCH_SUPPORTS_DEBUG_PAGEALLOC,
          fill the pages with poison patterns after free_pages() and verify
@@ -26,5 +26,69 @@ config DEBUG_PAGEALLOC
          that would result in incorrect warnings of memory corruption after
          a resume because free pages are not saved to the suspend image.
 
+         By default this option will have a small overhead, e.g. by not
+         allowing the kernel mapping to be backed by large pages on some
+         architectures. Even bigger overhead comes when the debugging is
+         enabled by DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc
+         command line parameter.
+
+config DEBUG_PAGEALLOC_ENABLE_DEFAULT
+       bool "Enable debug page memory allocations by default?"
+       default n
+       depends on DEBUG_PAGEALLOC
+       ---help---
+         Enable debug page memory allocations by default? This value
+         can be overridden by debug_pagealloc=off|on.
+
 config PAGE_POISONING
+       bool "Poison pages after freeing"
+       select PAGE_EXTENSION
+       select PAGE_POISONING_NO_SANITY if HIBERNATION
+       ---help---
+         Fill the pages with poison patterns after free_pages() and verify
+         the patterns before alloc_pages. The filling of the memory helps
+         reduce the risk of information leaks from freed data. This does
+         have a potential performance impact.
+
+         Note that "poison" here is not the same thing as the "HWPoison"
+         for CONFIG_MEMORY_FAILURE. This is software poisoning only.
+
+         If unsure, say N
+
+config PAGE_POISONING_NO_SANITY
+       depends on PAGE_POISONING
+       bool "Only poison, don't sanity check"
+       ---help---
+          Skip the sanity checking on alloc, only fill the pages with
+          poison on free. This reduces some of the overhead of the
+          poisoning feature.
+
+          If you are only interested in sanitization, say Y. Otherwise
+          say N.
+
+config PAGE_POISONING_ZERO
+       bool "Use zero for poisoning instead of random data"
+       depends on PAGE_POISONING
+       ---help---
+          Instead of using the existing poison value, fill the pages with
+          zeros. This makes it harder to detect when errors are occurring
+          due to sanitization but the zeroing at free means that it is
+          no longer necessary to write zeros when GFP_ZERO is used on
+          allocation.
+
+          Enabling page poisoning with this option will disable hibernation
+
+          If unsure, say N
        bool
+
+config DEBUG_PAGE_REF
+       bool "Enable tracepoint to track down page reference manipulation"
+       depends on DEBUG_KERNEL
+       depends on TRACEPOINTS
+       ---help---
+         This is a feature to add tracepoint for tracking down page reference
+         manipulation. This tracking is useful to diagnose functional failure
+         due to migration failures caused by page reference mismatches.  Be
+         careful when enabling this feature because it adds about 30 KB to the
+         kernel code.  However the runtime performance overhead is virtually
+         nil until the tracepoints are actually enabled.