[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

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

[David Hildenbrand (Arm)]

On 11/10/26 12:26, Yuanhe Shu wrote:

While the file touches highmem.h, this really isn't about highmem at all, right?

This really affects any architecture except the ones that define
copy_mc_to_kernel (x86+powerpc).

Or am I missing something? Would be good to clarify that.

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

CCing Catalin. I'm surprised that arm64 cannot recover from a copy from a
hwpoisoned page.


-- 
Cheers,

David

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

[Kefeng Wang]

On 11/11/2026 5:36 PM, David Hildenbrand (Arm) wrote:
> On 11/10/26 12:26, Yuanhe Shu wrote:
> 
> While the file touches highmem.h, this really isn't about highmem at all, right?
> 
> This really affects any architecture except the ones that define
> copy_mc_to_kernel (x86+powerpc).
> 
> Or am I missing something? Would be good to clarify that.
> 
>> 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.
> 
> CCing Catalin. I'm surprised that arm64 cannot recover from a copy from a
> hwpoisoned page.
> 

+1

We have been trying to support this feature in the mainline for over
three years. This year, Alibaba took over and released new v14 and v15[1].

In server scenarios, COPY_MC is very useful because it helps avoid
unnecessary panic behavior in the system. We would like to receive some
guidance to accelerate the integration of this feature into the
mainline.

CCed Ruidong/Tiangen

[1] v15 
https://lore.kernel.org/linux-arm-kernel/20260618092124.3901230-1-tianruidong@linux.alibaba.com/

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

[Weilin Tong]

Hi Kefeng, David, Catalin, Tiangen, and Ying,

Thank you for raising this and for the continued work and review
on arm64 COPY_MC support.

I would like to provide an update on our side. Ruidong has left
Alibaba and is no longer focusing on kernel development. I will
be taking over the development and upstreaming of the arm64
ARCH_HAS_COPY_MC series, building on Tiangen's and Ruidong's work.

This work is already underway. I will follow up on the feedback
from previous revisions and plan to submit an updated series
in the near future.

I have also added my colleagues Shuai Xue and Baolin Wang to Cc.
Please keep me copied on further discussions of this series.
Any additional guidance on outstanding issues or priorities for
the next revision would be appreciated.

Best regards,
Weilin