diff mbox series

[v1] mm, hwpoison: do not lock page again when me_huge_page() successfully recovers

Message ID 20210304064437.962442-1-nao.horiguchi@gmail.com (mailing list archive)
State New, archived
Headers show
Series [v1] mm, hwpoison: do not lock page again when me_huge_page() successfully recovers | expand

Commit Message

Naoya Horiguchi March 4, 2021, 6:44 a.m. UTC 
From: Naoya Horiguchi <naoya.horiguchi@nec.com>

Currently me_huge_page() temporary unlocks page to perform some actions
then locks it again later. My testcase (which calls hard-offline on some
tail page in a hugetlb, then accesses the address of the hugetlb range)
showed that page allocation code detects the page lock on buddy page and
printed out "BUG: Bad page state" message.  PG_hwpoison does not prevent
it because PG_hwpoison flag is set on any subpage of the hugetlb page
but the 2nd page lock is on the head page.

This patch suggests to drop the 2nd page lock to fix the issue.

Fixes: commit 78bb920344b8 ("mm: hwpoison: dissolve in-use hugepage in unrecoverable memory error")
Cc: stable@vger.kernel.org
Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
---
 mm/memory-failure.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Oscar Salvador March 5, 2021, 7:26 a.m. UTC | #1 
On Thu, Mar 04, 2021 at 03:44:37PM +0900, Naoya Horiguchi wrote:
> From: Naoya Horiguchi <naoya.horiguchi@nec.com>

Hi Naoya,

good catch!

> Currently me_huge_page() temporary unlocks page to perform some actions
> then locks it again later. My testcase (which calls hard-offline on some
> tail page in a hugetlb, then accesses the address of the hugetlb range)
> showed that page allocation code detects the page lock on buddy page and
> printed out "BUG: Bad page state" message.  PG_hwpoison does not prevent
> it because PG_hwpoison flag is set on any subpage of the hugetlb page
> but the 2nd page lock is on the head page.

I am having difficulties to parse "PG_hwpoison does not prevent it because
PG_hwpoison flag is set on any subpage of the hugetlb page".

What do you mean by that?

> 
> This patch suggests to drop the 2nd page lock to fix the issue.
> 
> Fixes: commit 78bb920344b8 ("mm: hwpoison: dissolve in-use hugepage in unrecoverable memory error")
> Cc: stable@vger.kernel.org
> Signed-off-by: Naoya Horiguchi <naoya.horiguchi@nec.com>

The fix looks fine to me:

Reviewed-by: Oscar Salvador <osalvador@suse.de>
diff mbox series

Patch

diff --git v5.11/mm/memory-failure.c v5.11_patched/mm/memory-failure.c
index e9481632fcd1..d8aba15295c5 100644
--- v5.11/mm/memory-failure.c
+++ v5.11_patched/mm/memory-failure.c
@@ -830,7 +830,6 @@  static int me_huge_page(struct page *p, unsigned long pfn)
 			page_ref_inc(p);
 			res = MF_RECOVERED;
 		}
-		lock_page(hpage);
 	}
 
 	return res;
@@ -1286,7 +1285,8 @@  static int memory_failure_hugetlb(unsigned long pfn, int flags)
 
 	res = identify_page_state(pfn, p, page_flags);
 out:
-	unlock_page(head);
+	if (PageLocked(head))
+		unlock_page(head);
 	return res;
 }