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

[Rik van Riel <riel@surriel.com>]

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.



-- 
All Rights Reversed.