mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

             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®