+ mm-hwpoison-fix-condition-in-free-hugetlb-page-path.patch added to -mm tree
From: akpm@linux-foundation.org
Date: 2021-12-10 17:01:01
Also in:
mm-commits
The patch titled
Subject: mm, hwpoison: fix condition in free hugetlb page path
has been added to the -mm tree. Its filename is
mm-hwpoison-fix-condition-in-free-hugetlb-page-path.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/mm-hwpoison-fix-condition-in-free-hugetlb-page-path.patch
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/mm-hwpoison-fix-condition-in-free-hugetlb-page-path.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Naoya Horiguchi <redacted>
Subject: mm, hwpoison: fix condition in free hugetlb page path
When a memory error hits a tail page of a free hugepage,
__page_handle_poison() is expected to be called to isolate the error in
4kB unit, but it's not called due to the outdated if-condition in
memory_failure_hugetlb(). This loses the chance to isolate the error in
the finer unit, so it's not optimal. Drop the condition.
This "(p != head && TestSetPageHWPoison(head)" condition is based on the
old semantics of PageHWPoison on hugepage (where PG_hwpoison flag was set
on the subpage), so it's not necessray any more. By getting to set
PG_hwpoison on head page for hugepages, concurrent error events on
different subpages in a single hugepage can be prevented by
TestSetPageHWPoison(head) at the beginning of memory_failure_hugetlb().
So dropping the condition should not reopen the race window originally
mentioned in commit b985194c8c0a ("hwpoison, hugetlb:
lock_page/unlock_page does not match for handling a free hugepage")
Link: https://lkml.kernel.org/r/20211210110208.879740-1-naoya.horiguchi@linux.dev
Signed-off-by: Naoya Horiguchi <redacted>
Reported-by: Fei Luo <redacted>
Cc: <redacted> [5.14+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memory-failure.c | 21 +++++++--------------
1 file changed, 7 insertions(+), 14 deletions(-)
--- a/mm/memory-failure.c~mm-hwpoison-fix-condition-in-free-hugetlb-page-path
+++ a/mm/memory-failure.c@@ -1470,24 +1470,17 @@ static int memory_failure_hugetlb(unsign if (!(flags & MF_COUNT_INCREASED)) { res = get_hwpoison_page(p, flags); if (!res) { - /* - * Check "filter hit" and "race with other subpage." - */ lock_page(head); - if (PageHWPoison(head)) { - if ((hwpoison_filter(p) && TestClearPageHWPoison(p)) - || (p != head && TestSetPageHWPoison(head))) { + if (hwpoison_filter(p)) { + if (TestClearPageHWPoison(head)) num_poisoned_pages_dec(); - unlock_page(head); - return 0; - } + unlock_page(head); + return 0; } unlock_page(head); - res = MF_FAILED; - if (__page_handle_poison(p)) { - page_ref_inc(p); - res = MF_RECOVERED; - } + res = MF_RECOVERED; + if (!page_handle_poison(p, true, false)) + res = MF_FAILED; action_result(pfn, MF_MSG_FREE_HUGE, res); return res == MF_RECOVERED ? 0 : -EBUSY; } else if (res < 0) {
_ Patches currently in -mm which might be from naoya.horiguchi@nec.com are mm-hwpoison-fix-condition-in-free-hugetlb-page-path.patch mm-hwpoison-mf_mutex-for-soft-offline-and-unpoison.patch mm-hwpoison-remove-mf_msg_buddy_2nd-and-mf_msg_poisoned_huge.patch mm-hwpoison-fix-unpoison_memory.patch