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

[Catalin Marinas <catalin.marinas@arm.com>]

On Wed, Nov 11, 2026 at 10:36:40AM +0100, David Hildenbrand 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).

I think is_page_hwpoison() is compiled out unless CONFIG_MEMORY_FAILURE
is enabled. Only arm64, parisc, powerpc and x86 enable it with the
latter two having proper mc support.

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

Yeah, it's been around for some time. Lack of review cycles on our side
as well.

-- 
Catalin