* Freeing HugeTLB page into buddy allocator
@ 2017-04-25 8:57 Anshuman Khandual
2017-04-27 5:54 ` Naoya Horiguchi
0 siblings, 1 reply; 3+ messages in thread
From: Anshuman Khandual @ 2017-04-25 8:57 UTC (permalink / raw)
To: wujianguo
Cc: n-horiguchi, Linux Memory Management List, Linux Kernel Mailing List
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
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: Freeing HugeTLB page into buddy allocator
2017-04-25 8:57 Freeing HugeTLB page into buddy allocator Anshuman Khandual
@ 2017-04-27 5:54 ` Naoya Horiguchi
2017-04-27 11:06 ` Anshuman Khandual
0 siblings, 1 reply; 3+ messages in thread
From: Naoya Horiguchi @ 2017-04-27 5:54 UTC (permalink / raw)
To: Anshuman Khandual
Cc: wujianguo, Linux Memory Management List, Linux Kernel Mailing List
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
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Freeing HugeTLB page into buddy allocator
2017-04-27 5:54 ` Naoya Horiguchi
@ 2017-04-27 11:06 ` Anshuman Khandual
0 siblings, 0 replies; 3+ messages in thread
From: Anshuman Khandual @ 2017-04-27 11:06 UTC (permalink / raw)
To: Naoya Horiguchi, Anshuman Khandual
Cc: wujianguo, Linux Memory Management List, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-04-27 11:08 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-25 8:57 Freeing HugeTLB page into buddy allocator Anshuman Khandual
2017-04-27 5:54 ` Naoya Horiguchi
2017-04-27 11:06 ` Anshuman Khandual
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).