Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1630314 > unrolled thread
| Started by | Anshuman Khandual <khandual@linux.vnet.ibm.com> |
|---|---|
| First post | 2017-04-25 11:00 +0200 |
| Last post | 2017-04-27 13:20 +0200 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
Freeing HugeTLB page into buddy allocator Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-04-25 11:00 +0200
Re: Freeing HugeTLB page into buddy allocator Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> - 2017-04-27 08:00 +0200
Re: Freeing HugeTLB page into buddy allocator Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-04-27 13:20 +0200
| From | Anshuman Khandual <khandual@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-04-25 11:00 +0200 |
| Subject | Freeing HugeTLB page into buddy allocator |
| Message-ID | <tA4ud-2ow-9@gated-at.bofh.it> |
Hello Jianguo,
In the commit a49ecbcd7b0d5a1cda, it talks about HugeTLB page being
freed into buddy allocator instead of hugepage_freelists. But if
I look the code closely for the function unmap_and_move_huge_page()
it only calls putback_active_hugepage() which puts the page into the
huge page active list to free up the source HugeTLB page after any
successful migration. I might be missing something here, so can you
please point me where we release the HugeTLB page into buddy allocator
directly during migration ?
commit a49ecbcd7b0d5a1cda7d60e03df402dd0ef76ac8
Author: Jianguo Wu <wujianguo@huawei.com>
Date: Wed Dec 18 17:08:54 2013 -0800
mm/memory-failure.c: recheck PageHuge() after hugetlb page migrate successfully
After a successful hugetlb page migration by soft offline, the source
page will either be freed into hugepage_freelists or buddy(over-commit
page). If page is in buddy, page_hstate(page) will be NULL. It will
hit a NULL pointer dereference in dequeue_hwpoisoned_huge_page().
BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
IP: [<ffffffff81163761>] dequeue_hwpoisoned_huge_page+0x131/0x1d0
PGD c23762067 PUD c24be2067 PMD 0
Oops: 0000 [#1] SMP
So check PageHuge(page) after call migrate_pages() successfully.
Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
Tested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index b7c1716..db08af9 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1505,10 +1505,16 @@ static int soft_offline_huge_page(struct page *page, int flags)
if (ret > 0)
ret = -EIO;
} else {
- set_page_hwpoison_huge_page(hpage);
- dequeue_hwpoisoned_huge_page(hpage);
- atomic_long_add(1 << compound_order(hpage),
- &num_poisoned_pages);
+ /* overcommit hugetlb page will be freed to buddy */
+ if (PageHuge(page)) {
+ set_page_hwpoison_huge_page(hpage);
+ dequeue_hwpoisoned_huge_page(hpage);
+ atomic_long_add(1 << compound_order(hpage),
+ &num_poisoned_pages);
+ } else {
+ SetPageHWPoison(page);
+ atomic_long_inc(&num_poisoned_pages);
+ }
}
return ret;
}
Regards
Anshuman
[toc] | [next] | [standalone]
| From | Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> |
|---|---|
| Date | 2017-04-27 08:00 +0200 |
| Message-ID | <tAKD8-4DF-5@gated-at.bofh.it> |
| In reply to | #1630314 |
On Tue, Apr 25, 2017 at 02:27:27PM +0530, Anshuman Khandual wrote:
> Hello Jianguo,
>
> In the commit a49ecbcd7b0d5a1cda, it talks about HugeTLB page being
> freed into buddy allocator instead of hugepage_freelists. But if
> I look the code closely for the function unmap_and_move_huge_page()
> it only calls putback_active_hugepage() which puts the page into the
> huge page active list to free up the source HugeTLB page after any
> successful migration. I might be missing something here, so can you
> please point me where we release the HugeTLB page into buddy allocator
> directly during migration ?
Hi Anshuman,
As stated in the patch description, source hugetlb page is freed after
successful migration if overcommit is configured.
The call chain is like below:
soft_offline_huge_page
migrate_pages
unmap_and_move_huge_page
putback_active_hugepage(hpage)
put_page // refcount is down to 0
__put_page
__put_compound_page
free_huge_page
if (h->surplus_huge_pages_node[nid])
update_and_free_page
__free_pages
So the inline comment
+ /* overcommit hugetlb page will be freed to buddy */
might be confusing because at this point the overcommit hugetlb page was
already freed to buddy.
I hope this will help you.
Thanks,
Naoya Horiguchi
>
>
> commit a49ecbcd7b0d5a1cda7d60e03df402dd0ef76ac8
> Author: Jianguo Wu <wujianguo@huawei.com>
> Date: Wed Dec 18 17:08:54 2013 -0800
>
> mm/memory-failure.c: recheck PageHuge() after hugetlb page migrate successfully
>
> After a successful hugetlb page migration by soft offline, the source
> page will either be freed into hugepage_freelists or buddy(over-commit
> page). If page is in buddy, page_hstate(page) will be NULL. It will
> hit a NULL pointer dereference in dequeue_hwpoisoned_huge_page().
>
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
> IP: [<ffffffff81163761>] dequeue_hwpoisoned_huge_page+0x131/0x1d0
> PGD c23762067 PUD c24be2067 PMD 0
> Oops: 0000 [#1] SMP
>
> So check PageHuge(page) after call migrate_pages() successfully.
>
> Signed-off-by: Jianguo Wu <wujianguo@huawei.com>
> Tested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index b7c1716..db08af9 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1505,10 +1505,16 @@ static int soft_offline_huge_page(struct page *page, int flags)
> if (ret > 0)
> ret = -EIO;
> } else {
> - set_page_hwpoison_huge_page(hpage);
> - dequeue_hwpoisoned_huge_page(hpage);
> - atomic_long_add(1 << compound_order(hpage),
> - &num_poisoned_pages);
> + /* overcommit hugetlb page will be freed to buddy */
> + if (PageHuge(page)) {
> + set_page_hwpoison_huge_page(hpage);
> + dequeue_hwpoisoned_huge_page(hpage);
> + atomic_long_add(1 << compound_order(hpage),
> + &num_poisoned_pages);
> + } else {
> + SetPageHWPoison(page);
> + atomic_long_inc(&num_poisoned_pages);
> + }
> }
> return ret;
> }
>
> Regards
> Anshuman
>
>
[toc] | [prev] | [next] | [standalone]
| From | Anshuman Khandual <khandual@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-04-27 13:20 +0200 |
| Message-ID | <tAPCN-8aG-3@gated-at.bofh.it> |
| In reply to | #1631878 |
On 04/27/2017 11:24 AM, Naoya Horiguchi wrote: > On Tue, Apr 25, 2017 at 02:27:27PM +0530, Anshuman Khandual wrote: >> Hello Jianguo, >> >> In the commit a49ecbcd7b0d5a1cda, it talks about HugeTLB page being >> freed into buddy allocator instead of hugepage_freelists. But if >> I look the code closely for the function unmap_and_move_huge_page() >> it only calls putback_active_hugepage() which puts the page into the >> huge page active list to free up the source HugeTLB page after any >> successful migration. I might be missing something here, so can you >> please point me where we release the HugeTLB page into buddy allocator >> directly during migration ? > > Hi Anshuman, > > As stated in the patch description, source hugetlb page is freed after > successful migration if overcommit is configured. > > The call chain is like below: > > soft_offline_huge_page > migrate_pages > unmap_and_move_huge_page > putback_active_hugepage(hpage) > put_page // refcount is down to 0 > __put_page > __put_compound_page > free_huge_page > if (h->surplus_huge_pages_node[nid]) > update_and_free_page > __free_pages > > So the inline comment > > + /* overcommit hugetlb page will be freed to buddy */ > > might be confusing because at this point the overcommit hugetlb page was > already freed to buddy. > > I hope this will help you. Surely does. Thanks Naoya.
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web