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

[David Hildenbrand (Arm)]

On 10/31/26 00:35, Andrew Morton wrote:
> 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"?

I think above should say "There isn't really something that would prevent
concurrent truncation."

> 
> 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?

It's splitting (min_order_for_split() reading ->mapping) racing with truncate
(changing ->mapping).

Want to fix up the s/folio split/truncate/ when applying or want me to resend?

Thanks¡

-- 
Cheers,

David