|  | config PAGE_EXTENSION | 
|  | bool "Extend memmap on extra space for more information on page" | 
|  | ---help--- | 
|  | Extend memmap on extra space for more information on page. This | 
|  | could be used for debugging features that need to insert extra | 
|  | field for every page. This extension enables us to save memory | 
|  | by not allocating this extra memory according to boottime | 
|  | configuration. | 
|  |  | 
|  | config DEBUG_PAGEALLOC | 
|  | bool "Debug page memory allocations" | 
|  | depends on DEBUG_KERNEL | 
|  | depends on !HIBERNATION || ARCH_SUPPORTS_DEBUG_PAGEALLOC && !PPC && !SPARC | 
|  | depends on !KMEMCHECK | 
|  | select PAGE_EXTENSION | 
|  | select PAGE_POISONING if !ARCH_SUPPORTS_DEBUG_PAGEALLOC | 
|  | ---help--- | 
|  | Unmap pages from the kernel linear mapping after free_pages(). | 
|  | 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 | 
|  | the patterns before alloc_pages().  Additionally, | 
|  | this option cannot be enabled in combination with hibernation as | 
|  | 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. | 
|  |  | 
|  | 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. |