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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3dfb5722-f81f-4712-af9a-9ea074fb792d@redhat.com>
Date: Wed, 22 Oct 2025 22:34:14 +0200
From: David Hildenbrand <david@...hat.com>
To: Zi Yan <ziy@...dia.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.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?

> 
> 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 :)

-- 
Cheers

David / dhildenb