[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 2 Feb 2016 02:19:14 +0000
From: Naoya Horiguchi <n-horiguchi@...jp.nec.com>
To: Mike Kravetz <mike.kravetz@...cle.com>
CC: "linux-mm@...ck.org" <linux-mm@...ck.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Michal Hocko <mhocko@...e.cz>,
"David Rientjes" <rientjes@...gle.com>
Subject: Re: kernel BUG at mm/hugetlb.c:1218!
On Mon, Feb 01, 2016 at 05:23:53PM -0800, Mike Kravetz wrote:
> I just noticed that recent mmotm and linux-next kernels will not boot if
> you attempt to preallocate 1G huge pages at boot time (on x86). To
> preallocate, simply add "hugepagesz=1G hugepages=1" to kernel command
> line. I have not yet started to debug. However, based on the
> "BUG_ON(page_mapcount(page));" I am guessing it is related to recent
> mapcount/refcount changes.
Hi Mike,
Thank you for reporting.
Comparing prep_compound_page() and prep_compound_gigantic_page(),
prep_compound_gigantic_page() doesn't initialize compound_mapcount,
so simply doing like below should fix this (I briefly confirmed it.)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 8afd5fc09f70..9b931134e9df 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1286,6 +1286,7 @@ static void prep_compound_gigantic_page(struct page *page, unsigned int order)
set_page_count(p, 0);
set_compound_head(p, page);
}
+ atomic_set(compound_mapcount_ptr(page), -1);
}
/*
BTW, BUG_ON() in free_huge_page() can be replaced with improved version
of VM_BUG_ON_PAGE() to help our debugging. Could you work on it, too?
Thanks,
Naoya Horiguchi
Powered by blists - more mailing lists