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

[Kefeng Wang <wangkefeng.wang@huawei.com>]

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/