Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1323704
| 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 |
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 | Next — Previous in thread | Find similar | Unroll 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