Re: [PATCH v5 3/3] mm/huge_memory: fix kernel-doc comments for folio_split() and related.

David Hildenbrand (Red Hat)
2025-11-03T16:39:01Z

> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index ad2fc52651a6..a30fee2001b5 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3586,7 +3586,7 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
> * uniform_split is true.
> * 2. buddy allocator like (non-uniform) split: the given @folio is split into
> * half and one of the half (containing the given page) is split into half
> - * until the given @page's order becomes @new_order. This is done when
> + * until the given @folio's order becomes @new_order. This is done when
> * uniform_split is false.
> *
> * The high level flow for these two methods are:
> @@ -3595,14 +3595,14 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
> * along with stats update.
> * 2. non-uniform split: folio_order - @new_order calls to
> * __split_folio_to_order() are expected to be made in a for loop to split
> - * the @folio to one lower order at a time. The folio containing @page is
> - * split in each iteration. @xas is split into half in each iteration and
> + * the @folio to one lower order at a time. The folio containing @split_at
> + * is split in each iteration. @xas is split into half in each iteration and
> * can fail. A failed @xas split leaves split folios as is without merging
> * them back.
> *
> * After splitting, the caller's folio reference will be transferred to the
> - * folio containing @page. The caller needs to unlock and/or free after-split
> - * folios if necessary.
> + * folio containing @split_at. The caller needs to unlock and/or free
> + * after-split folios if necessary.
> *
> * Return: 0 - successful, <0 - failed (if -ENOMEM is returned, @folio might be
> * split but not to @new_order, the caller needs to check)

Acked-by: David Hildenbrand (Red Hat) <david@kernel.org>

--
Cheers

David