From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752005AbcBBCVA (ORCPT <rfc822;w@1wt.eu>);
	Mon, 1 Feb 2016 21:21:00 -0500
Received: from TYO201.gate.nec.co.jp ([210.143.35.51]:45404 "EHLO
	tyo201.gate.nec.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751342AbcBBCU7 convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 1 Feb 2016 21:20:59 -0500
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
CC: "linux-mm@kvack.org" <linux-mm@kvack.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Michal Hocko <mhocko@suse.cz>, "David Rientjes" <rientjes@google.com>
Subject: Re: kernel BUG at mm/hugetlb.c:1218!
Thread-Topic: kernel BUG at mm/hugetlb.c:1218!
Thread-Index: AQHRXVhkgHsqkcArv02H4a60tNNPt58XbqaA
Date: Tue, 2 Feb 2016 02:19:14 +0000
Message-ID: <20160202021913.GA12609@hori1.linux.bs1.fc.nec.co.jp>
References: <56B00529.6080807@oracle.com>
In-Reply-To: <56B00529.6080807@oracle.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.128.101.16]
Content-Type: text/plain; charset="iso-2022-jp"
Content-ID: <B2F31B753B28C64395E9477FC4BBF45C@gisp.nec.co.jp>
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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