| 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. |