Re: kernel BUG at mm/hugetlb.c:1218!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]