Re: [PATCH 1/2] mm/compaction: skip folios containing hwpoisoned pages

From: Kaitao Cheng

Date: Thu Oct 22 2026 - 08:39:46 EST




在 2026/10/21 16:27, David Hildenbrand (Arm) 写道:
> On 10/21/26 04:49, Kaitao Cheng wrote:
>>
>>
>> 在 2026/10/20 21:58, David Hildenbrand (Arm) 写道:
>>> On 10/20/26 15:31, Kaitao Cheng wrote:
>>>>
>>>>
>>>> 在 2026/10/20 21:07, David Hildenbrand (Arm) 写道:
>>>>
>>>> It does require architecture support, but that doesn't seem practical, haha.
>>>
>>> Well, but that's required when an arch wants to rule out all races.
>>>
>>>>> Will architectures that are not prepared for copy_mc_user_highpage() not simply
>>>>> crash if they trigger an MCE during an access?

After thinking about it, if the memcpy here is guaranteed to cause a crash,
wouldn't the system inevitably crash at some point anyway, even if we check
folio_contain_hwpoisoned_page() beforehand and return early, since this kind
of memory error is unrecoverable?

If the system won't crash, it seems fine to defer the check as well.

>>>>
>>>> Do we need to check both before and after the copy? This feels a bit
>>>> redundant, and I'm not sure whether such a small race window warrants
>>>> an additional check.
>>>>
>>>
>>> I don't see how checking after the copy makes any sense? :)
>>>
>>> You already crashed if there was a problem, why check? Or what am I missing?
>> In cases such as transient errors, software poison injection, repeated
>> bit flips in memory, or bit flips in the ECC check bits themselves, a
>> page may be faulty while memcpy() still completes normally. If the copied
>> data is correct, only the PG_hwpoison flag is lost during migration. But
>> if the copied data is corrupted and the kernel or a process subsequently
>> treats it as valid, I think the consequences could be more serious than
>> an immediate crash. However, I cannot estimate how likely this is to happen.
> That's the point, me neither. I'm happy to perform checks before access, or
> after, in the default copy implementation, but I want to have properly
> documented how this makes sense and which races exist.
>
Here are a few subtle corner cases I came up with. They may be extremely
unlikely to occur.

case A:
CPU 1 CPU 2

if (folio_contain_hwpoisoned_page()) The check passes because
return -EHWPOISON; PG_hwpoisoned is not set.

A transient bus error occurs,
or the flag is injected by software.

PG_hwpoisoned is set.

The bus temporarily returns to normal.

memcpy(new, old); The copy succeeds and copies
the correct data.

PG_hwpoisoned is not propagated
to the new page, so the flag is lost.


case B:
CPU 1 CPU 2

if (folio_contain_hwpoisoned_page())
return -EHWPOISON;

A memory bit flips, causing
an ECC error.

PG_hwpoisoned is set.

Other bits in the same byte then flip,
or the ECC check bits themselves flip.

ECC check passes.

memcpy(new, old); The copy succeeds but copies
corrupted data.

PG_hwpoisoned is lost.

The kernel or user treats
the corrupted data as valid.


--
Thanks
Kaitao Cheng