Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1323704

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

From Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Newsgroups linux.kernel
Subject Re: kernel BUG at mm/hugetlb.c:1218!
Date 2016-02-02 03:30 +0100
Message-ID <qXyT7-3SA-1@gated-at.bofh.it> (permalink)
References <qXxX4-3bW-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

kernel BUG at mm/hugetlb.c:1218! Mike Kravetz <mike.kravetz@oracle.com> - 2016-02-02 02:30 +0100
  Re: kernel BUG at mm/hugetlb.c:1218! Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> - 2016-02-02 03:30 +0100

csiph-web