Re: [PATCH v5 10/17] mm/huge_memory: move the racy refcount check into unmap_folio()

[David Hildenbrand (Arm)]

On 9/14/26 19:14, Kairui Song via B4 Relay wrote:
> From: Kairui Song <kasong@xxxxxxxxxxx>
> 
> The check only exists to avoid the expensive PMD-splitting unmap of a
> folio that cannot be split anyway.  Move it from __folio_split() into

and folio_split_unmapped()

> unmap_folio(), right before the PMD split, so both the anon and file
> split helpers get the early check without repeating it.
> 
> unmap_folio() now returns -EAGAIN if the check fails and the split
> helpers propagate the error.  folio_split_unmapped() drops its own
> copy of the check: it works on already unmapped folios and the
> definitive folio_ref_freeze() in __folio_freeze_split_anon() still
> catches unexpected references.
> 
> Reviewed-by: Zi Yan <ziy@xxxxxxxxxx>
> Reviewed-by: Kiryl Shutsemau (Meta) <kas@xxxxxxxxxx>
> Signed-off-by: Kairui Song <kasong@xxxxxxxxxxx>
> ---
>  mm/huge_memory.c | 29 +++++++++++++----------------
>  1 file changed, 13 insertions(+), 16 deletions(-)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 77bf68c9b9af..859aefda7356 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3539,13 +3539,17 @@ void vma_adjust_trans_huge(struct vm_area_struct *vma,
>  		split_huge_pmd_if_needed(next, end);
>  }
>  
> -static void unmap_folio(struct folio *folio)
> +static int unmap_folio(struct folio *folio)

The semantics are special: a return value of 0 does not mean that unmapping
succeeded. It might have still failed, but remap_anon_folio() must be called
afterwards (for anon folios). Might be worth a quick comment.

In general, LGTM.

Acked-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>

-- 
Cheers,

David