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

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

在 2026/10/11 21:14, Huang, Ying 写道:
> Yuanhe Shu <xiangzao@linux.alibaba.com> writes:
> 
>> On 9/28/26 20:12, David Hildenbrand wrote:
>>> On 9/28/26 12:58, Yuanhe Shu wrote:
>>>> folio_mc_copy() does not close this hole: it only detects corruption
>>>> at copy time and only where ARCH_HAS_COPY_MC is implemented (x86_64
>>>> and PPC64; elsewhere copy_mc_highpage() degrades to a plain copy).
>>>
>>> Then they should implement it.
>>
>> Agreed, and nothing here replaces copy_mc.  Two things the check adds
>> while that work is pending: on archs without copy_mc the plain copy
>> does not fail, it consumes the poison - the same poison consumption
>> commit 841a8bfcbad9 ("mm: prevent poison consumption when splitting
>> THP") refused to risk on the split path, at your suggestion; and the
>> refusal happens before the copy is attempted at all, while copy_mc
>> recovers only during the read.  The check and copy_mc compose.
>>
> 
> Is it good to implement the trick in copy_mc_user_highpage() and
> copy_mc_highpage() if the macro copy_mc_to_kernel is undefined?

On architectures with hardware error correction and exception recovery
support, accessing faulty memory automatically triggers an exception,
which itself guarantees atomicity.

On architectures without such support, even if we implement this logic
in copy_mc_user_highpage() and copy_mc_highpage(), checking the hwpoison
flag and copying the data remain two separate operations. They cannot
be performed atomically, so there is still a race window between them,
however small.

Moving the hwpoison check after the copy might address this issue.
Is there anything wrong with my understanding?

> ---
> Best Regards,
> Huang, Ying

-- 
Thanks
Kaitao Cheng