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

Groups > linux.kernel > #1324695 > unrolled thread

[PATCH] mm/hugetlb: fix gigantic page initialization/allocation

Started byMike Kravetz <mike.kravetz@oracle.com>
First post2016-02-02 23:40 +0100
Last post2016-02-03 00:00 +0100
Articles 7 — 5 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH] mm/hugetlb: fix gigantic page initialization/allocation Mike Kravetz <mike.kravetz@oracle.com> - 2016-02-02 23:40 +0100
    Re: [PATCH] mm/hugetlb: fix gigantic page  initialization/allocation David Rientjes <rientjes@google.com> - 2016-02-03 00:00 +0100
      Re: [PATCH] mm/hugetlb: fix gigantic page initialization/allocation Mike Kravetz <mike.kravetz@oracle.com> - 2016-02-03 00:20 +0100
        Re: [PATCH] mm/hugetlb: fix gigantic page initialization/allocation Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> - 2016-02-03 04:10 +0100
          Re: [PATCH] mm/hugetlb: fix gigantic page initialization/allocation Mike Kravetz <mike.kravetz@oracle.com> - 2016-02-03 05:20 +0100
            Re: [PATCH] mm/hugetlb: fix gigantic page initialization/allocation Vlastimil Babka <vbabka@suse.cz> - 2016-02-05 13:00 +0100
    Re: [PATCH] mm/hugetlb: fix gigantic page initialization/allocation "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-02-03 00:00 +0100

#1324695 — [PATCH] mm/hugetlb: fix gigantic page initialization/allocation

FromMike Kravetz <mike.kravetz@oracle.com>
Date2016-02-02 23:40 +0100
Subject[PATCH] mm/hugetlb: fix gigantic page initialization/allocation
Message-ID<qXRM5-1qu-1@gated-at.bofh.it>
Attempting to preallocate 1G gigantic huge pages at boot time with
"hugepagesz=1G hugepages=1" on the kernel command line will prevent
booting with the following:

kernel BUG at mm/hugetlb.c:1218!

When mapcount accounting was reworked, the setting of compound_mapcount_ptr
in prep_compound_gigantic_page was overlooked.  As a result, the validation
of mapcount in free_huge_page fails.

The "BUG_ON" checks in free_huge_page were also changed to "VM_BUG_ON_PAGE"
to assist with debugging.

Fixes: af5642a8af ("mm: rework mapcount accounting to enable 4k mapping of THPs")
Suggested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
---
 mm/hugetlb.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 12908dc..d7a8024 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1214,8 +1214,8 @@ void free_huge_page(struct page *page)
 
 	set_page_private(page, 0);
 	page->mapping = NULL;
-	BUG_ON(page_count(page));
-	BUG_ON(page_mapcount(page));
+	VM_BUG_ON_PAGE(page_count(page), page);
+	VM_BUG_ON_PAGE(page_mapcount(page), page);
 	restore_reserve = PagePrivate(page);
 	ClearPagePrivate(page);
 
@@ -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);
 }
 
 /*
-- 
2.4.3

[toc] | [next] | [standalone]

#1324706 — Re: [PATCH] mm/hugetlb: fix gigantic page initialization/allocation

FromDavid Rientjes <rientjes@google.com>
Date2016-02-03 00:00 +0100
SubjectRe: [PATCH] mm/hugetlb: fix gigantic page initialization/allocation
Message-ID<qXS5r-1xR-3@gated-at.bofh.it>
In reply to#1324695
On Tue, 2 Feb 2016, Mike Kravetz wrote:

> Attempting to preallocate 1G gigantic huge pages at boot time with
> "hugepagesz=1G hugepages=1" on the kernel command line will prevent
> booting with the following:
> 
> kernel BUG at mm/hugetlb.c:1218!
> 
> When mapcount accounting was reworked, the setting of compound_mapcount_ptr
> in prep_compound_gigantic_page was overlooked.  As a result, the validation
> of mapcount in free_huge_page fails.
> 
> The "BUG_ON" checks in free_huge_page were also changed to "VM_BUG_ON_PAGE"
> to assist with debugging.
> 
> Fixes: af5642a8af ("mm: rework mapcount accounting to enable 4k mapping of THPs")
> Suggested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>

I'm not sure whether this should have a "From: Naoya Horiguchi" line with 
an accompanying sign-off or not, since Naoya debugged and wrote the actual 
fix to prep_compound_gigantic_page().

Acked-by: David Rientjes <rientjes@google.com>

[toc] | [prev] | [next] | [standalone]

#1324725

FromMike Kravetz <mike.kravetz@oracle.com>
Date2016-02-03 00:20 +0100
Message-ID<qXSoP-1XH-23@gated-at.bofh.it>
In reply to#1324706
On 02/02/2016 02:59 PM, David Rientjes wrote:
> On Tue, 2 Feb 2016, Mike Kravetz wrote:
> 
>> Attempting to preallocate 1G gigantic huge pages at boot time with
>> "hugepagesz=1G hugepages=1" on the kernel command line will prevent
>> booting with the following:
>>
>> kernel BUG at mm/hugetlb.c:1218!
>>
>> When mapcount accounting was reworked, the setting of compound_mapcount_ptr
>> in prep_compound_gigantic_page was overlooked.  As a result, the validation
>> of mapcount in free_huge_page fails.
>>
>> The "BUG_ON" checks in free_huge_page were also changed to "VM_BUG_ON_PAGE"
>> to assist with debugging.
>>
>> Fixes: af5642a8af ("mm: rework mapcount accounting to enable 4k mapping of THPs")
>> Suggested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
> 
> I'm not sure whether this should have a "From: Naoya Horiguchi" line with 
> an accompanying sign-off or not, since Naoya debugged and wrote the actual 
> fix to prep_compound_gigantic_page().

I agree.  Naoya did debug and provide fix via e-mail exchange.  He did not
sign-off and I could not tell if he was going to pursue.  My only intention
was to fix ASAP.

More than happy to give Naoya credit.
-- 
Mike Kravetz

> 
> Acked-by: David Rientjes <rientjes@google.com>
>

[toc] | [prev] | [next] | [standalone]

#1324851

FromNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date2016-02-03 04:10 +0100
Message-ID<qXVZo-4BL-11@gated-at.bofh.it>
In reply to#1324725
On Tue, Feb 02, 2016 at 03:17:10PM -0800, Mike Kravetz wrote:
> On 02/02/2016 02:59 PM, David Rientjes wrote:
> > On Tue, 2 Feb 2016, Mike Kravetz wrote:
> > 
> >> Attempting to preallocate 1G gigantic huge pages at boot time with
> >> "hugepagesz=1G hugepages=1" on the kernel command line will prevent
> >> booting with the following:
> >>
> >> kernel BUG at mm/hugetlb.c:1218!
> >>
> >> When mapcount accounting was reworked, the setting of compound_mapcount_ptr
> >> in prep_compound_gigantic_page was overlooked.  As a result, the validation
> >> of mapcount in free_huge_page fails.
> >>
> >> The "BUG_ON" checks in free_huge_page were also changed to "VM_BUG_ON_PAGE"
> >> to assist with debugging.
> >>
> >> Fixes: af5642a8af ("mm: rework mapcount accounting to enable 4k mapping of THPs")
> >> Suggested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> >> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
> > 
> > I'm not sure whether this should have a "From: Naoya Horiguchi" line with 
> > an accompanying sign-off or not, since Naoya debugged and wrote the actual 
> > fix to prep_compound_gigantic_page().
> 
> I agree.  Naoya did debug and provide fix via e-mail exchange.  He did not
> sign-off and I could not tell if he was going to pursue.  My only intention
> was to fix ASAP.
> 
> More than happy to give Naoya credit.

Thank you! It's great if you append my signed-off below yours.

Naoya

[toc] | [prev] | [next] | [standalone]

#1324908

FromMike Kravetz <mike.kravetz@oracle.com>
Date2016-02-03 05:20 +0100
Message-ID<qXX58-5ma-25@gated-at.bofh.it>
In reply to#1324851
On 02/02/2016 07:01 PM, Naoya Horiguchi wrote:
> On Tue, Feb 02, 2016 at 03:17:10PM -0800, Mike Kravetz wrote:
>> I agree.  Naoya did debug and provide fix via e-mail exchange.  He did not
>> sign-off and I could not tell if he was going to pursue.  My only intention
>> was to fix ASAP.
>>
>> More than happy to give Naoya credit.
> 
> Thank you! It's great if you append my signed-off below yours.
> 
> Naoya

Adding Naoya's sign off and Acks received

mm/hugetlb: fix gigantic page initialization/allocation

Attempting to preallocate 1G gigantic huge pages at boot time with
"hugepagesz=1G hugepages=1" on the kernel command line will prevent
booting with the following:

kernel BUG at mm/hugetlb.c:1218!

When mapcount accounting was reworked, the setting of compound_mapcount_ptr
in prep_compound_gigantic_page was overlooked.  As a result, the validation
of mapcount in free_huge_page fails.

The "BUG_ON" checks in free_huge_page were also changed to "VM_BUG_ON_PAGE"
to assist with debugging.

Fixes: af5642a8af ("mm: rework mapcount accounting to enable 4k mapping
of THPs")
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: David Rientjes <rientjes@google.com>
---
 mm/hugetlb.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 12908dc..d7a8024 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1214,8 +1214,8 @@ void free_huge_page(struct page *page)

 	set_page_private(page, 0);
 	page->mapping = NULL;
-	BUG_ON(page_count(page));
-	BUG_ON(page_mapcount(page));
+	VM_BUG_ON_PAGE(page_count(page), page);
+	VM_BUG_ON_PAGE(page_mapcount(page), page);
 	restore_reserve = PagePrivate(page);
 	ClearPagePrivate(page);

@@ -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);
 }

 /*
-- 
2.4.3

[toc] | [prev] | [next] | [standalone]

#1327620

FromVlastimil Babka <vbabka@suse.cz>
Date2016-02-05 13:00 +0100
Message-ID<qYNdo-85k-25@gated-at.bofh.it>
In reply to#1324908
On 02/03/2016 05:15 AM, Mike Kravetz wrote:
> On 02/02/2016 07:01 PM, Naoya Horiguchi wrote:
>> On Tue, Feb 02, 2016 at 03:17:10PM -0800, Mike Kravetz wrote:
>>> I agree.  Naoya did debug and provide fix via e-mail exchange.  He did not
>>> sign-off and I could not tell if he was going to pursue.  My only intention
>>> was to fix ASAP.
>>>
>>> More than happy to give Naoya credit.
>>
>> Thank you! It's great if you append my signed-off below yours.
>>
>> Naoya
> 
> Adding Naoya's sign off and Acks received
> 
> mm/hugetlb: fix gigantic page initialization/allocation
> 
> Attempting to preallocate 1G gigantic huge pages at boot time with
> "hugepagesz=1G hugepages=1" on the kernel command line will prevent
> booting with the following:
> 
> kernel BUG at mm/hugetlb.c:1218!
> 
> When mapcount accounting was reworked, the setting of compound_mapcount_ptr
> in prep_compound_gigantic_page was overlooked.  As a result, the validation
> of mapcount in free_huge_page fails.
> 
> The "BUG_ON" checks in free_huge_page were also changed to "VM_BUG_ON_PAGE"
> to assist with debugging.
> 
> Fixes: af5642a8af ("mm: rework mapcount accounting to enable 4k mapping
> of THPs")
> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Acked-by: David Rientjes <rientjes@google.com>

Tested-by: Vlastimil Babka <vbabka@suse.cz>

[toc] | [prev] | [next] | [standalone]

#1324711

From"Kirill A. Shutemov" <kirill@shutemov.name>
Date2016-02-03 00:00 +0100
Message-ID<qXS5s-1xR-19@gated-at.bofh.it>
In reply to#1324695
On Tue, Feb 02, 2016 at 02:33:40PM -0800, Mike Kravetz wrote:
> Attempting to preallocate 1G gigantic huge pages at boot time with
> "hugepagesz=1G hugepages=1" on the kernel command line will prevent
> booting with the following:
> 
> kernel BUG at mm/hugetlb.c:1218!
> 
> When mapcount accounting was reworked, the setting of compound_mapcount_ptr
> in prep_compound_gigantic_page was overlooked.  As a result, the validation
> of mapcount in free_huge_page fails.

Oops. Soory for that.

> 
> The "BUG_ON" checks in free_huge_page were also changed to "VM_BUG_ON_PAGE"
> to assist with debugging.
> 
> Fixes: af5642a8af ("mm: rework mapcount accounting to enable 4k mapping of THPs")
> Suggested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>

Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

> ---
>  mm/hugetlb.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 12908dc..d7a8024 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1214,8 +1214,8 @@ void free_huge_page(struct page *page)
>  
>  	set_page_private(page, 0);
>  	page->mapping = NULL;
> -	BUG_ON(page_count(page));
> -	BUG_ON(page_mapcount(page));
> +	VM_BUG_ON_PAGE(page_count(page), page);
> +	VM_BUG_ON_PAGE(page_mapcount(page), page);
>  	restore_reserve = PagePrivate(page);
>  	ClearPagePrivate(page);
>  
> @@ -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);
>  }
>  
>  /*
> -- 
> 2.4.3
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

-- 
 Kirill A. Shutemov

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web