| 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. |
| |
| Enabling page poisoning with this option will disable hibernation |
| |
| If unsure, say N |