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

[Kaitao Cheng <kaitao.cheng@linux.dev>]

在 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