On 01/25/2016 10:39 PM, Jianyu Zhan wrote:
On Tue, Jan 26, 2016 at 12:55 AM, Laura Abbott <labbott@xxxxxxxxxxxxxxxxx> wrote:--- a/mm/debug-pagealloc.c +++ b/mm/debug-pagealloc.c @@ -8,11 +8,5 @@ void __kernel_map_pages(struct page *page, int numpages, int enable) { - if (!page_poisoning_enabled()) - return; - - if (enable) - unpoison_pages(page, numpages); - else - poison_pages(page, numpages); + kernel_poison_pages(page, numpages, enable); } diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 63358d9..c733421 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1002,6 +1002,7 @@ static bool free_pages_prepare(struct page *page, unsigned int order) PAGE_SIZE << order); } arch_free_page(page, order); + kernel_poison_pages(page, 1 << order, 0); kernel_map_pages(page, 1 << order, 0); return true; @@ -1396,6 +1397,7 @@ static int prep_new_page(struct page *page, unsigned int order, gfp_t gfp_flags, set_page_refcounted(page); arch_alloc_page(page, order); + kernel_poison_pages(page, 1 << order, 1); kernel_map_pages(page, 1 << order, 1); kasan_alloc_pages(page, order);kernel_map_pages() will fall back to page poisoning scheme for !ARCH_SUPPORTS_DEBUG_PAGEALLOC. IIUC, calling kernel_poison_pages() before kernel_map_pages() will be equivalent to call kernel_poison_pages() twice?!
Yes, you are absolutely right. In the !ARCH_SUPPORTS_DEBUG_PAGEALLOC case we shouldn't need to do anything in kernel_map_pages.
Thanks, Jianyu Zhan
Thanks, Laura -- 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>