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

[Lance Yang]

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!