From: Yuanhe Shu <xiangzao@linux.alibaba.com>
To: akpm@linux-foundation.org
Cc: david@kernel.org, "Huang, Ying" <ying.huang@linux.alibaba.com>,
Kaitao Cheng <kaitao.cheng@linux.dev>,
vbabka@kernel.org, linmiaohe@huawei.com, nao.horiguchi@gmail.com,
ziy@nvidia.com, wangkefeng.wang@huawei.com,
tujinjiang@huawei.com, mgorman@techsingularity.net,
chengkaitao@kylinos.cn, muchun.song@linux.dev,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
xiangzao@linux.alibaba.com
Subject: [PATCH v2 0/2] mm: don't migrate folios containing hwpoisoned pages
Date: Mon, 26 Oct 2026 10:55:50 +0800 [thread overview]
Message-ID: <20261026025552.1427901-1-xiangzao@linux.alibaba.com> (raw)
v2 of this series. No changes to the approach; the two deltas are a
wording correction promised in the v1 discussion and a third check
suggested by Kaitao Cheng.
memory_failure() can end up abandoning a folio while PG_hwpoison is
already set on it. Two ways to get there:
1. Race: any isolator (compaction, NUMA balancing, move_pages(),
mbind(), CMA, long-term GUP) clears PG_lru from under
memory_failure(), which then fails the HWPoisonHandlable()
check, exhausts the get_any_page() retries and bails out with
MF_IGNORED - without holding any reference, but with the flag
set.
2. No race at all: the THP-split-failure path
(kill_procs_now() + MF_MSG_UNSPLIT_THP) leaves a large folio
on the LRU with a PG_hwpoisoned subpage by design.
In both cases the migrator still holds the folio on its migration
list and migrates it like any other: the corrupted data is copied
into a fresh folio with no poison marker, and no hwpoison PTE entry
is installed on the way back, so the userspace mapping is silently
redirected to the corrupted copy - no SIGBUS is ever delivered.
This was reproduced on v7.3-rc4-75-g62f4c998b297 (the base of
this series): an order-0 stress workload (madvise(MADV_HWPOISON)
racing move_pages()) left the poison flag set on 8426 abandoned
folios in a 180-second run; 698 of them were subsequently
migrated, and in every case the address then served the copied
corrupted data with no SIGBUS. With patch 2, 0 of 9711 were
propagated.
The compaction-side guard is needed regardless of how the race in
memory_failure() itself might be addressed: the steady state
(split failure leaves the folio on the LRU with the flag already
set) is not a race at all. Deterministically validated 16/16
poisoned mTHP folios migrated unpatched vs 0/16 with patch 1,
with clean controls migrating 16/16 in both runs.
The checks compose with, not replace, copy_mc: folio_mc_copy()
still catches real-DRAM corruption during the copy on archs that
implement it, and the flag checks refuse software-injected poison
on all archs before and after the copy. Extending the
!ARCH_HAS_COPY_MC fallbacks of copy_mc_user_highpage() and
copy_mc_highpage() with the same flag check - which would also
cover their non-migration callers - was proposed by Huang, Ying
and welcomed by David in the v1 discussion; that is posted as a
separate patch right after this series.
Changes since v1:
- Patch 1: the isolation check's claim is narrowed to folios that
are already flagged when compaction sees them ("avoids the
migration of a folio that is already flagged"); a poison landing
after isolation is patch 2's business, as David pointed out.
- Patch 2: a third check after the copy, before the mapping is
transferred, suggested by Kaitao Cheng. It closes the copy
window itself, which the debugfs corrupt-pfn injector can hit
since it has no GUP or PTE ordering constraint. In the v1
racing workload the pre-copy checks already propagated 0 of
9711, so the new check is measured-neutral there.
- Both patches carry Assisted-by: LLM, as promised in the v1
discussion.
Yuanhe Shu (2):
mm/compaction: skip folios containing hwpoisoned pages
mm/migrate: refuse to migrate folios containing hwpoisoned pages
mm/compaction.c | 8 ++++++++
mm/migrate.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 55 insertions(+), 2 deletions(-)
base-commit: 62f4c998b297cf233997a2b4cd6fc2d2df0319c9
--
2.43.7
next reply other threads:[~2026-10-26 2:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 2:55 Yuanhe Shu [this message]
2026-10-26 2:55 ` [PATCH v2 1/2] mm/compaction: skip " Yuanhe Shu
2026-10-26 2:55 ` [PATCH v2 2/2] mm/migrate: refuse to migrate " Yuanhe Shu
2026-10-26 9:56 ` [PATCH v2 0/2] mm: don't " David Hildenbrand (Arm)
2026-10-27 12:08 ` Yuanhe Shu
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=20261026025552.1427901-1-xiangzao@linux.alibaba.com \
--to=xiangzao@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=chengkaitao@kylinos.cn \
--cc=david@kernel.org \
--cc=kaitao.cheng@linux.dev \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=muchun.song@linux.dev \
--cc=nao.horiguchi@gmail.com \
--cc=tujinjiang@huawei.com \
--cc=vbabka@kernel.org \
--cc=wangkefeng.wang@huawei.com \
--cc=ying.huang@linux.alibaba.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®