Re: [PATCH v3 1/4] mm/huge_memory: preserve PG_has_hwpoisoned if a folio is split to >0 order

[Zi Yan <ziy@nvidia.com>]

On 22 Oct 2025, at 16:34, David Hildenbrand wrote:

> On 22.10.25 22:27, Zi Yan wrote:
>> On 22 Oct 2025, at 16:09, David Hildenbrand wrote:
>>
>>> On 22.10.25 05:35, Zi Yan wrote:
>>>> folio split clears PG_has_hwpoisoned, but the flag should be preserved in
>>>> after-split folios containing pages with PG_hwpoisoned flag if the folio is
>>>> split to >0 order folios. Scan all pages in a to-be-split folio to
>>>> determine which after-split folios need the flag.
>>>>
>>>> An alternatives is to change PG_has_hwpoisoned to PG_maybe_hwpoisoned to
>>>> avoid the scan and set it on all after-split folios, but resulting false
>>>> positive has undesirable negative impact. To remove false positive, caller
>>>> of folio_test_has_hwpoisoned() and folio_contain_hwpoisoned_page() needs to
>>>> do the scan. That might be causing a hassle for current and future callers
>>>> and more costly than doing the scan in the split code. More details are
>>>> discussed in [1].
>>>>
>>>> It is OK that current implementation does not do this, because memory
>>>> failure code always tries to split to order-0 folios and if a folio cannot
>>>> be split to order-0, memory failure code either gives warnings or the split
>>>> is not performed.
>>>>
>>>
>>> We're losing PG_has_hwpoisoned for large folios, so likely this should be
>>> a stable fix for splitting anything to an order > 0 ?
>>
>> I was the borderline on this, because:
>>
>> 1. before the hotfix, which prevents silently bumping target split order,
>>     memory failure would give a warning when a folio is split to >0 order
>>     folios. The warning is masking this issue.
>> 2. after the hotfix, folios with PG_has_hwpoisoned will not be split
>>     to >0 order folios since memory failure always wants to split a folio
>>     to order 0 and a folio containing LBS folios will not be split, thus
>>     without losing PG_has_hwpoisoned.
>>
>
> I was rather wondering about something like
>
> a) memory failure wants to split to some order (order-0?) but fails the split (e.g., raised reference). hwpoison is set.
>
> b) Later, something else (truncation?) wants to split to order > 0 and loses the hwpoison bit.
>
> Would that be possible?

Yeah, that is possible after commit 7460b470a131 ("mm/truncate: use folio_split()
in truncate operation") when truncation splits a folio to >0 order folios.

>
>>
>> I will add
>> Fixes: c010d47f107f ("mm: thp: split huge page to any lower order pages")
>> and cc stable in the next version.
>
> That would be better I think. But then you have to pull this patch out as well from this series, gah :)

Yep, let me tell this horrible story in the cover letter.

--
Best Regards,
Yan, Zi