Re: [PATCH] mm/huge_memory: fix a folio_split() race condition with folio_try_get()

[David Hildenbrand (Arm)]

On 2/28/26 02:06, Zi Yan wrote:
> During a pagecache folio split, the values in the related xarray should not
> be changed from the original folio at xarray split time until all
> after-split folios are well formed and stored in the xarray. Current use
> of xas_try_split() in __split_unmapped_folio() lets some after-split folios
> show up at wrong indices in the xarray. When these misplaced after-split
> folios are unfrozen, before correct folios are stored via __xa_store(), and
> grabbed by folio_try_get(), they are returned to userspace at wrong file
> indices, causing data corruption.
> 
> Fix it by using the original folio in xas_try_split() calls, so that
> folio_try_get() can get the right after-split folios after the original
> folio is unfrozen.
> 
> Uniform split, split_huge_page*(), is not affected, since it uses
> xas_split_alloc() and xas_split() only once and stores the original folio
> in the xarray.

Could we make both code paths similar and store the original folio in
both cases?

IIUC, the __xa_store() is performed unconditionally after
__split_unmapped_folio().

I'm wondering, though, about the "new_folio->index >= end" case.
Wouldn't we leave some stale entries in the xarray? But that handling
has always been confusing to me :)

-- 
Cheers,

David