Message-ID: <8416106F-EA1E-4995-BAC2-7EE9FEB4D0C3@nvidia.com>
Date: Wed, 22 Oct 2025 16:40:26 -0400
From: Zi Yan <ziy@...dia.com>
To: David Hildenbrand <david@...hat.com>
Cc: linmiaohe@...wei.com, jane.chu@...cle.com, kernel@...kajraghav.com,
 akpm@...ux-foundation.org, mcgrof@...nel.org, nao.horiguchi@...il.com,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Baolin Wang <baolin.wang@...ux.alibaba.com>,
 "Liam R. Howlett" <Liam.Howlett@...cle.com>, Nico Pache <npache@...hat.com>,
 Ryan Roberts <ryan.roberts@....com>, Dev Jain <dev.jain@....com>,
 Barry Song <baohua@...nel.org>, Lance Yang <lance.yang@...ux.dev>,
 "Matthew Wilcox (Oracle)" <willy@...radead.org>,
 Wei Yang <richard.weiyang@...il.com>, Yang Shi <shy828301@...il.com>,
 linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org
Subject: Re: [PATCH v3 1/4] mm/huge_memory: preserve PG_has_hwpoisoned if a
 folio is split to >0 order

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

Powered by blists - more mailing lists