Messages in this thread Patch in this message | | | From | Naoya Horiguchi <> | Subject | Re: kernel BUG at mm/hugetlb.c:1218! | Date | Tue, 2 Feb 2016 02:19:14 +0000 |
| |
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
| |