mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yuanhe Shu <xiangzao@linux.alibaba.com>
To: akpm@linux-foundation.org, david@kernel.org
Cc: "Huang, Ying" <ying.huang@linux.alibaba.com>,
	Kaitao Cheng <kaitao.cheng@linux.dev>,
	vbabka@kernel.org, ljs@kernel.org, liam@infradead.org,
	rppt@kernel.org, surenb@google.com, mhocko@suse.com,
	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] mm/highmem: refuse to copy hwpoisoned folios in the !copy_mc fallbacks
Date: Mon, 26 Oct 2026 10:57:24 +0800	[thread overview]
Message-ID: <20261026025724.1430747-1-xiangzao@linux.alibaba.com> (raw)

Where copy_mc_to_kernel is defined, copy_mc_user_highpage() and
copy_mc_highpage() stop at a hardware error during the copy, report
the not-copied bytes and queue the source page for memory_failure().
The !copy_mc fallbacks return 0 after a plain copy instead.  With
PG_hwpoison set while the data stays readable - software-injected
poison (MADV_HWPOISON, the debugfs corrupt-pfn injector) or a
transient hardware error - there is no fault to recover from: the
copy completes, the destination folio carries no poison marker, and
the poison is consumed silently, the same poison consumption
commit 841a8bfcbad9 ("mm: prevent poison consumption when splitting
THP") refused to risk on the split path.

Check the source folio with folio_contain_hwpoisoned_page() in both
fallbacks and return PAGE_SIZE, the not-copied-bytes convention of
the real copy_mc paths, so the callers take their existing error
paths: the COW and fork paths fail with -EHWPOISON, KSM and
khugepaged abort, and folio_mc_copy() propagates to the migration
core, where this composes with the separate migration-side checks.
On archs with copy_mc this code does not compile.

The check runs after the copy: a check before it would leave open
the window between itself and the copy.  A flag set before or during
the copy is caught, whatever state the data is in.  A late software
injection cannot have corrupted the completed copy, and a synchronous
hardware error takes an arch without copy_mc down at the access; the
residue no flag check, before or after, can catch is corruption whose
hardware report lands after the last check.  Closing that would need
architecture support, as discussed.

The fallbacks do not queue memory_failure() on refusal: the flag is
already set, and memory failure either knows about the page or has
abandoned it.

Suggested-by: "Huang, Ying" <ying.huang@linux.alibaba.com>
Suggested-by: Kaitao Cheng <kaitao.cheng@linux.dev>
Assisted-by: LLM
Signed-off-by: Yuanhe Shu <xiangzao@linux.alibaba.com>
Link: https://lore.kernel.org/r/877bjowf9i.fsf@DESKTOP-5N7EMDA/
---
 include/linux/highmem.h | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index d7aac9de1c8a..f90f0c6204a4 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -474,12 +474,21 @@ static inline int copy_mc_user_highpage(struct page *to, struct page *from,
 					unsigned long vaddr, struct vm_area_struct *vma)
 {
 	copy_user_highpage(to, from, vaddr, vma);
+	/*
+	 * The flag can be set while the copy runs, so check after it;
+	 * a flag landing later can no longer have corrupted this copy.
+	 */
+	if (folio_contain_hwpoisoned_page(page_folio(from)))
+		return PAGE_SIZE;
 	return 0;
 }
 
 static inline int copy_mc_highpage(struct page *to, struct page *from)
 {
 	copy_highpage(to, from);
+	/* Same reasoning as in copy_mc_user_highpage(). */
+	if (folio_contain_hwpoisoned_page(page_folio(from)))
+		return PAGE_SIZE;
 	return 0;
 }
 #endif
-- 
2.43.7


             reply	other threads:[~2026-10-26  2:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-26  2:57 Yuanhe Shu [this message]
2026-10-26  9:55 ` David Hildenbrand (Arm)
2026-10-26 11:21 ` Huang, Ying
2026-10-26 12:17   ` Garg, Shivank
2026-10-26 12:09 ` Garg, Shivank

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=20261026025724.1430747-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=liam@infradead.org \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=nao.horiguchi@gmail.com \
    --cc=rppt@kernel.org \
    --cc=surenb@google.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®