Re: [PATCH] mm/huge_memory: set PG_has_hwpoisoned only after new folio head is established

[Lance Yang <lance.yang@linux.dev>]

On 2026/7/2 01:24, Rik van Riel wrote:
> On Wed, 2026-07-01 at 18:33 +0200, David Hildenbrand (Arm) wrote:
>>
>> There is some grammatical issue that makes me wonder whether you are
>> talking
>> about the present or the past.
>>>
> 
> Changelog issues fixed for v2. Thank you.
> 
>>> Reproduced by syzkaller: hwpoison-inject a few subpages of a large
>>> shmem
>>> folio, then MADV_REMOVE (fallocate punch hole) on the same range,
>>> which
>>> splits the partial folio to a non-zero order.
>>
>> As Lance says, after we do the TestSetPageHWPoison() in
>> memory_failure(), we
>> call try_to_split_thp_page(). Does that already suffice, even without
>> the
>> MADV_REMOCE.
> 
> While fa5a06170036 was created to deal with having
> the folio split to >0 order, in this case it looks
> like the try_to_split_thp_page() call from memory_failure()
> failed, presumably because folio_ref_freeze() could not
> freeze the order 7 folio, because the reproducer had
> multiple threads poking at that folio simultaneously.
> 
> This test case is rather contrived, like most syzkaller
> tests, but given that the try_to_split_thp_page() call
> could fail for various reasons, we do need this fallback
> path.

Should be rare, but yeah, there it is. Wondered if the hwpoison-time
split had failed somehow ... turns out it did :)

Thanks for spelling that out!