Re: Linux-next: crash in alloc_huge_page()

[Mike Rapoport]

On Wed, Aug 11, 2021 at 04:06:18AM +0100, Matthew Wilcox wrote:
> On Tue, Aug 10, 2021 at 10:22:37PM -0400, Qian Cai wrote:
> > and the page->lru has an address fffffffffffffffc for some reasons. Does it sound like some error code
> > had not been handled properly and had been propagated here instead? I tried reverting a few recent
> > commits for mm/hugetlb.c and mm/memblock.c without luck so far.
> 
> Yes, ff..fc is going to be at offset 8 from the actual address, so
> that's -12 and -12 is ...
> 
> #define ENOMEM          12      /* Out of memory */
> 
> so something's returning ERR_PTR(-ENOMEM) instead of NULL.

page is not initialized in alloc_buddy_huge_page_with_mpol() and after
commit 2cfa8b23744f ("mm-hugetlb-add-support-for-mempolicy-mpol_preferred_many-fix") we have 

	struct page *page;

	...

	if (mpol_is_preferred_many(mpol)) {
		gfp_t gfp = gfp_mask | __GFP_NOWARN;

		gfp &=  ~(__GFP_DIRECT_RECLAIM | __GFP_NOFAIL);
		page = alloc_surplus_huge_page(h, gfp, nid, nodemask, false);

		/* Fallback to all nodes if page==NULL */
		nodemask = NULL;
	}

	if (!page)
		page = alloc_surplus_huge_page(h, gfp_mask, nid, nodemask, false

	mpol_cond_put(mpol);
	return page;

so for !mpol_is_preferred_many() we return an uninitialized variable.

This should fix it:

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 008662083fec..6337697f7ee4 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2152,7 +2152,7 @@ static
 struct page *alloc_buddy_huge_page_with_mpol(struct hstate *h,
 		struct vm_area_struct *vma, unsigned long addr)
 {
-	struct page *page;
+	struct page *page = NULL;
 	struct mempolicy *mpol;
 	gfp_t gfp_mask = htlb_alloc_mask(h);
 	int nid;
 
-- 
Sincerely yours,
Mike.