[PATCH v3] mm/highmem: refuse to copy hwpoisoned folios in the !copy_mc fallbacks

[PATCH v3] mm/highmem: refuse to copy hwpoisoned folios in the !copy_mc fallbacks

[Yuanhe Shu]

The !copy_mc fallbacks of copy_mc_user_highpage() and
copy_mc_highpage() return 0 after a plain copy.  With PG_hwpoison
set while the data stays readable, there is no fault to recover
from: the copy completes, the destination folio carries no poison
marker, and the poison is consumed silently.

Check the source page with is_page_hwpoison() in both fallbacks,
before the copy, and return PAGE_SIZE, the not-copied-bytes
convention of the real copy_mc paths, so the callers take their
existing error paths.  On archs with copy_mc this code does not
compile.

Measured on arm64, where the fallback code compiles: a
kernel-space microbenchmark measures 90.00 ns per copy before the
patch and 90.71 ns after, 0.8% of the copy itself.

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/
---

Changes since v2:

v2: https://lore.kernel.org/r/20261029034254.2487998-1-xiangzao@linux.alibaba.com/

- Keep only the check before the copy (Huang Ying): the copy is
  back-to-back with the check, so a flag landing within the copy is
  negligible.

- Add the kernel-space microbenchmark asked for during v2 review
  (Huang Ying).  The bare copy and the copy with the check are
  interleaved in the same boot, 20 rounds of 200k copies each, with
  the CPU pinned; the zero-variance baseline bounds the resolution
  below 1 ns.

 include/linux/highmem.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index d7aac9de1c8a..c3240f70471d 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -473,12 +473,18 @@ static inline int copy_mc_highpage(struct page *to, struct page *from)
 static inline int copy_mc_user_highpage(struct page *to, struct page *from,
 					unsigned long vaddr, struct vm_area_struct *vma)
 {
+	/* Don't touch data that is already marked poisoned. */
+	if (is_page_hwpoison(from))
+		return PAGE_SIZE;
 	copy_user_highpage(to, from, vaddr, vma);
 	return 0;
 }
 
 static inline int copy_mc_highpage(struct page *to, struct page *from)
 {
+	/* Don't touch data that is already marked poisoned. */
+	if (is_page_hwpoison(from))
+		return PAGE_SIZE;
 	copy_highpage(to, from);
 	return 0;
 }
-- 
2.43.7

Re: [PATCH v3] mm/highmem: refuse to copy hwpoisoned folios in the !copy_mc fallbacks

[Huang, Ying]

Yuanhe Shu <xiangzao@linux.alibaba.com> writes:

> The !copy_mc fallbacks of copy_mc_user_highpage() and
> copy_mc_highpage() return 0 after a plain copy.  With PG_hwpoison
> set while the data stays readable, there is no fault to recover
> from: the copy completes, the destination folio carries no poison
> marker, and the poison is consumed silently.

IIUC, this is just RAS debug behavior, not real-world behavior.  When
poisoned memory is accessed, an MCE/SEA is triggered, and the kernel
will panic without a proper copy_mc_* implementation.  This patch
reduces the probability of a panic, which I think is its main value.

> Check the source page with is_page_hwpoison() in both fallbacks,
> before the copy, and return PAGE_SIZE, the not-copied-bytes
> convention of the real copy_mc paths, so the callers take their
> existing error paths.  On archs with copy_mc this code does not
> compile.
>
> Measured on arm64, where the fallback code compiles: a
> kernel-space microbenchmark measures 90.00 ns per copy before the
> patch and 90.71 ns after, 0.8% of the copy itself.
>
> 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/
> ---

---
Best Regards,
Huang, Ying