Hi Andrew, the whole thread started here: http://lkml.org/lkml/2014/1/6/217 I guess it makes sense to revert part of the already merged commit with the following patch. If the BUG_ON triggers again then we should rather find out why page_address_in_vma fails on anon_vma or f_mapping checks and not simply paper over it. --- >From 805035f35e8865f6233f88c78e7063512042afea Mon Sep 17 00:00:00 2001 From: Michal Hocko <mhocko@xxxxxxx> Date: Wed, 8 Jan 2014 10:57:41 +0100 Subject: [PATCH] mm: new_vma_page cannot see NULL vma for hugetlb pages 11c731e81bb0 (mm/mempolicy: fix !vma in new_vma_page()) has removed BUG_ON(!vma) from new_vma_page which is partially correct because page_address_in_vma will return EFAULT for non-linear mappings and at least shared shmem might be mapped this way. The patch also tried to prevent NULL ptr for hugetlb pages which is not correct AFAICS because hugetlb pages cannot be mapped as VM_NONLINEAR and other conditions in page_address_in_vma seem to be legit and catch real bugs. This patch restores BUG_ON for PageHuge to catch potential issues when the to-be-migrated page is not setup properly. Signed-off-by: Michal Hocko <mhocko@xxxxxxx> Reviewed-by: Bob Liu <bob.liu@xxxxxxxxxx> --- mm/mempolicy.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/mm/mempolicy.c b/mm/mempolicy.c index 9e8d2d86978a..1a368cd925ed 100644 --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -1199,10 +1199,8 @@ static struct page *new_vma_page(struct page *page, unsigned long private, int * } if (PageHuge(page)) { - if (vma) - return alloc_huge_page_noerr(vma, address, 1); - else - return NULL; + BUG_ON(!vma); + return alloc_huge_page_noerr(vma, address, 1); } /* * if !vma, alloc_page_vma() will use task or system default policy -- 1.8.5.2 -- Michal Hocko SUSE Labs -- 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>