On 3/7/2017 4:47 AM, Laura Abbott wrote: > On 03/06/2017 06:16 AM, Vinayak Menon wrote: >> On SPARSEMEM systems page poisoning is enabled after buddy is up, because >> of the dependency on page extension init. This causes the pages released >> by free_all_bootmem not to be poisoned. This either delays or misses >> the identification of some issues because the pages have to undergo another >> cycle of alloc-free-alloc for any corruption to be detected. >> Enable page poisoning early by getting rid of the PAGE_EXT_DEBUG_POISON >> flag. Since all the free pages will now be poisoned, the flag need not be >> verified before checking the poison during an alloc. >> >> Signed-off-by: Vinayak Menon <vinmenon@xxxxxxxxxxxxxx> >> --- >> >> Sending it as an RFC because I am not sure if I have missed a code path >> that can free pages to buddy skipping kernel_poison_pages, making >> the flag PAGE_EXT_DEBUG_POISON a necessity. >> > Have you tested this with hibernation? That's one place which tends > to cause problems with poisoning. Today I tried that on qemu and did not see any issue, and did not expect to hit any problems since CONFIG_PAGE_POISONING_NO_SANITY gets enabled with HIBERNATION. > > I'm curious what issues you've caught with this patch. This patch is used to catch corruptions during/soon after boot due to DDR instability. The free list can be traversed in a dump and corrupted physical addresses can be analyzed for patterns. But I think, this would also be useful in catching software induced corruptions which could be missed now because the page has to undergo a cycle of alloc-free-alloc for any corruption to be detected. And on systems with more RAM, it can take time for every page to complete this cycle. Thanks, Vinayak -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
