linux-kernel - Freeing HugeTLB page into buddy allocator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 25 Apr 2017 14:27:27 +0530
From:   Anshuman Khandual <khandual@...ux.vnet.ibm.com>
To:     wujianguo@...wei.com
Cc:     n-horiguchi@...jp.nec.com,
        Linux Memory Management List <linux-mm@...ck.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Freeing HugeTLB page into buddy allocator

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@...wei.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@...wei.com>
    Tested-by: Naoya Horiguchi <n-horiguchi@...jp.nec.com>
    Reviewed-by: Naoya Horiguchi <n-horiguchi@...jp.nec.com>
    Cc: <stable@...r.kernel.org>
    Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@...ux-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