Re: [PATCH v2] mm/memory-failure: fix folio refcount leak and min_order_for_split() locking

[Andrew Morton]

On Fri, 30 Oct 2026 23:29:13 +0100 "David Hildenbrand (Arm)" <david@xxxxxxxxxx> wrote:

> hwpoison code can end up calling min_order_for_split() without holding
> the folio lock. There isn't really something that would prevent
> concurrent folio split. Consequently folio->mapping can get set to
> NULL after checking for "!folio->mapping", and if the compiler
> reloads folio->mapping, mapping_min_folio_order() would try to
> dereference NULL.

Bit confused here.  Is it referring to folios which end up outside EOF
which split effectively truncates, or did it mean to say "truncate"?

If the former, how is split able to folio_ref_freeze() a folio which
hwpoison has grabbed a ref on?

IOW, is the race against split, or against truncate?