From: Jiaqi Yan <jiaqiyan@google.com>
To: linmiaohe@huawei.com, ljs@kernel.org, ziy@nvidia.com, vbabka@kernel.org
Cc: osalvador@kernel.org, harry.yoo@oracle.com, willy@infradead.org,
osalvador@suse.de, jackmanb@google.com, hannes@cmpxchg.org,
nao.horiguchi@gmail.com, david@kernel.org,
william.roche@oracle.com, tony.luck@intel.com,
wangkefeng.wang@huawei.com, jane.chu@oracle.com,
akpm@linux-foundation.org, muchun.song@linux.dev,
liam@infradead.org, rientjes@google.com, duenwen@google.com,
jthoughton@google.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, vbabka@suse.cz, rppt@kernel.org,
shuah@kernel.org, surenb@google.com, mhocko@suse.com,
boudewijn@delta-utec.com, Jiaqi Yan <jiaqiyan@google.com>
Subject: [PATCH v6 4/5] mm/memory-failure: skip take_page_off_buddy after dissolving HWPoison HugeTLB page
Date: Sun, 5 Jul 2026 18:07:13 +0000 [thread overview]
Message-ID: <20260705180714.3708947-5-jiaqiyan@google.com> (raw)
In-Reply-To: <20260705180714.3708947-1-jiaqiyan@google.com>
Now that HWPoison subpage(s) within HugeTLB page will be rejected by
buddy allocator during dissolve_free_hugetlb_folio(), there is no
need to drain_all_pages() and take_page_off_buddy() anymore. In fact,
calling take_page_off_buddy() after dissolve_free_hugetlb_folio()
succeeded returns false, making caller think __page_handle_poison()
failed.
Add __hugepage_handle_poison() and replace __page_handle_poison() at
HugeTLB specific call sites. The being handled HugeTLB page either
is free at the moment of try_memory_failure_hugetlb(), or becomes
free at the moment of me_huge_page().
Signed-off-by: Jiaqi Yan <jiaqiyan@google.com>
---
mm/memory-failure.c | 36 ++++++++++++++++++++++++++++++------
1 file changed, 30 insertions(+), 6 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 3d15b4c1b694..a37b67550718 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -174,6 +174,30 @@ static struct rb_root_cached pfn_space_itree = RB_ROOT_CACHED;
static DEFINE_MUTEX(pfn_space_lock);
/*
+ * Only for a HugeTLB page being handled by memory_failure(). The key
+ * difference to soft_offline() is that, no HWPoison subpage will make
+ * into buddy allocator after a successful dissolve_free_hugetlb_folio(),
+ * so take_page_off_buddy() is unnecessary.
+ */
+static int __hugepage_handle_poison(struct page *page)
+{
+ struct folio *folio = page_folio(page);
+
+ /*
+ * Can't use dissolve_free_hugetlb_folio() without a reliable
+ * raw_hwp_list telling which subpage is HWPoison. So do not free
+ * them to the buddy allocator. dequeue_hugetlb_folio_node_exact()
+ * will ensure to never re-allocate this hugepage.
+ */
+ if (folio_test_hugetlb_raw_hwp_unreliable(folio))
+ /* raw_hwp_list becomes unreliable when kmalloc() fails. */
+ return -ENOMEM;
+
+ return dissolve_free_hugetlb_folio(folio);
+}
+
+/*
+ * Only for a free or HugeTLB page being handled by soft_offline().
* Return values:
* 1: the page is dissolved (if needed) and taken off from buddy,
* 0: the page is dissolved (if needed) and not taken off from buddy,
@@ -1166,11 +1190,11 @@ static int me_huge_page(struct page_state *ps, struct page *p)
* subpages.
*/
folio_put(folio);
- if (__page_handle_poison(p) > 0) {
+ if (__hugepage_handle_poison(p)) {
+ res = MF_FAILED;
+ } else {
page_ref_inc(p);
res = MF_RECOVERED;
- } else {
- res = MF_FAILED;
}
}
@@ -2133,11 +2157,11 @@ static int try_memory_failure_hugetlb(unsigned long pfn, int flags)
*/
if (res == MF_HUGETLB_FREED) {
folio_unlock(folio);
- if (__page_handle_poison(p) > 0) {
+ if (__hugepage_handle_poison(p)) {
+ res = MF_FAILED;
+ } else {
page_ref_inc(p);
res = MF_RECOVERED;
- } else {
- res = MF_FAILED;
}
return action_result(pfn, MF_MSG_FREE_HUGE, res);
}
--
2.55.0.rc0.799.gd6f94ed593-goog
next prev parent reply other threads:[~2026-07-05 18:07 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-05 18:07 [PATCH v6 0/5] Only free healthy pages in high-order has_hwpoisoned folio Jiaqi Yan
2026-07-05 18:07 ` [PATCH v6 1/5] mm/page_alloc: introduce __free_prepared_contig_range() with fpi_t Jiaqi Yan
2026-07-17 7:17 ` Miaohe Lin
2026-07-22 9:38 ` Vlastimil Babka (SUSE)
2026-07-25 3:54 ` Matthew Wilcox
2026-08-17 0:28 ` Jiaqi Yan
2026-07-05 18:07 ` [PATCH v6 2/5] mm/page_alloc: only free healthy pages in high-order has_hwpoisoned folio Jiaqi Yan
2026-07-17 7:19 ` Miaohe Lin
2026-07-22 9:40 ` Vlastimil Babka (SUSE)
2026-07-05 18:07 ` [PATCH v6 3/5] mm/memory-failure: set has_hwpoisoned flags on dissolved HugeTLB folio Jiaqi Yan
2026-07-25 3:05 ` Jiaqi Yan
2026-07-05 18:07 ` Jiaqi Yan [this message]
2026-07-17 7:37 ` [PATCH v6 4/5] mm/memory-failure: skip take_page_off_buddy after dissolving HWPoison HugeTLB page Miaohe Lin
2026-08-17 0:29 ` Jiaqi Yan
2026-08-17 7:23 ` Miaohe Lin
2026-08-18 3:30 ` Jiaqi Yan
2026-08-18 9:06 ` Miaohe Lin
2026-07-05 18:07 ` [PATCH v6 5/5] selftests/mm: add hard memory failure anonymous HugeTLB test Jiaqi Yan
2026-07-17 7:37 ` Miaohe Lin
2026-07-25 3:05 ` Jiaqi Yan
2026-07-05 18:50 ` [PATCH v6 0/5] Only free healthy pages in high-order has_hwpoisoned folio Andrew Morton
2026-07-06 9:03 ` David Hildenbrand (Arm)
2026-07-25 3:06 ` Jiaqi Yan
2026-07-17 10:18 ` David Hildenbrand (Arm)
2026-07-17 13:06 ` William Roche
2026-07-22 8:27 ` Vlastimil Babka (SUSE)
2026-07-22 9:03 ` Vlastimil Babka (SUSE)
2026-07-25 6:00 ` Jiaqi Yan
2026-07-25 6:52 ` Jiaqi Yan
2026-07-27 14:20 ` David Hildenbrand (Arm)
2026-07-27 18:20 ` Matthew Wilcox
2026-07-28 17:18 ` Vlastimil Babka (SUSE)
2026-08-04 19:51 ` David Hildenbrand (Arm)
2026-08-05 8:58 ` Vlastimil Babka (SUSE)
2026-08-05 9:09 ` David Hildenbrand (Arm)
2026-08-28 23:36 ` Linux MM Alignment Session on hwpoison (was: Re: [PATCH v6 0/5] Only free healthy pages in high-order has_hwpoisoned folio) David Rientjes
2026-08-31 19:26 ` David Rientjes
2026-09-07 13:46 ` Linux MM Alignment Session on hwpoison David Hildenbrand (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260705180714.3708947-5-jiaqiyan@google.com \
--to=jiaqiyan@google.com \
--cc=akpm@linux-foundation.org \
--cc=boudewijn@delta-utec.com \
--cc=david@kernel.org \
--cc=duenwen@google.com \
--cc=hannes@cmpxchg.org \
--cc=harry.yoo@oracle.com \
--cc=jackmanb@google.com \
--cc=jane.chu@oracle.com \
--cc=jthoughton@google.com \
--cc=liam@infradead.org \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=nao.horiguchi@gmail.com \
--cc=osalvador@kernel.org \
--cc=osalvador@suse.de \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=tony.luck@intel.com \
--cc=vbabka@kernel.org \
--cc=vbabka@suse.cz \
--cc=wangkefeng.wang@huawei.com \
--cc=william.roche@oracle.com \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.