All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lance Yang <lance.yang@linux.dev>
To: Zi Yan <ziy@nvidia.com>
Cc: kernel@pankajraghav.com, jane.chu@oracle.com,
	akpm@linux-foundation.org, mcgrof@kernel.org,
	nao.horiguchi@gmail.com, david@redhat.com,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Nico Pache <npache@redhat.com>,
	linmiaohe@huawei.com, Ryan Roberts <ryan.roberts@arm.com>,
	Dev Jain <dev.jain@arm.com>, Barry Song <baohua@kernel.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Wei Yang <richard.weiyang@gmail.com>,
	Yang Shi <shy828301@gmail.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH v4 3/3] mm/huge_memory: fix kernel-doc comments for folio_split() and related.
Date: Thu, 30 Oct 2025 10:31:12 +0800	[thread overview]
Message-ID: <17dea8a6-b473-44da-82d2-d84223b7cdf1@linux.dev> (raw)
In-Reply-To: <20251030014020.475659-4-ziy@nvidia.com>



On 2025/10/30 09:40, Zi Yan wrote:
> try_folio_split_to_order(), folio_split, __folio_split(), and
> __split_unmapped_folio() do not have correct kernel-doc comment format.
> Fix them.
> 
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Acked-by: David Hildenbrand <david@redhat.com>
> ---

LGTM.

Reviewed-by: Lance Yang <lance.yang@linux.dev>

>   include/linux/huge_mm.h | 10 ++++++----
>   mm/huge_memory.c        | 27 +++++++++++++++------------
>   2 files changed, 21 insertions(+), 16 deletions(-)
> 
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index 34f8d8453bf3..cbb2243f8e56 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -386,9 +386,9 @@ static inline int split_huge_page_to_order(struct page *page, unsigned int new_o
>   	return split_huge_page_to_list_to_order(page, NULL, new_order);
>   }
>   
> -/*
> - * try_folio_split_to_order - try to split a @folio at @page to @new_order using
> - * non uniform split.
> +/**
> + * try_folio_split_to_order() - try to split a @folio at @page to @new_order
> + * using non uniform split.
>    * @folio: folio to be split
>    * @page: split to @new_order at the given page
>    * @new_order: the target split order
> @@ -398,7 +398,7 @@ static inline int split_huge_page_to_order(struct page *page, unsigned int new_o
>    * folios are put back to LRU list. Use min_order_for_split() to get the lower
>    * bound of @new_order.
>    *
> - * Return: 0: split is successful, otherwise split failed.
> + * Return: 0 - split is successful, otherwise split failed.
>    */
>   static inline int try_folio_split_to_order(struct folio *folio,
>   		struct page *page, unsigned int new_order)
> @@ -486,6 +486,8 @@ static inline spinlock_t *pud_trans_huge_lock(pud_t *pud,
>   /**
>    * folio_test_pmd_mappable - Can we map this folio with a PMD?
>    * @folio: The folio to test
> + *
> + * Return: true - @folio can be mapped, false - @folio cannot be mapped.
>    */
>   static inline bool folio_test_pmd_mappable(struct folio *folio)
>   {
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 0e24bb7e90d0..381a49c5ac3f 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3567,8 +3567,9 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
>   		ClearPageCompound(&folio->page);
>   }
>   
> -/*
> - * It splits an unmapped @folio to lower order smaller folios in two ways.
> +/**
> + * __split_unmapped_folio() - splits an unmapped @folio to lower order folios in
> + * two ways: uniform split or non-uniform split.
>    * @folio: the to-be-split folio
>    * @new_order: the smallest order of the after split folios (since buddy
>    *             allocator like split generates folios with orders from @folio's
> @@ -3603,8 +3604,8 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
>    * folio containing @page. The caller needs to unlock and/or free after-split
>    * folios if necessary.
>    *
> - * For !uniform_split, when -ENOMEM is returned, the original folio might be
> - * split. The caller needs to check the input folio.
> + * Return: 0 - successful, <0 - failed (if -ENOMEM is returned, @folio might be
> + * split but not to @new_order, the caller needs to check)
>    */
>   static int __split_unmapped_folio(struct folio *folio, int new_order,
>   		struct page *split_at, struct xa_state *xas,
> @@ -3722,8 +3723,8 @@ bool uniform_split_supported(struct folio *folio, unsigned int new_order,
>   	return true;
>   }
>   
> -/*
> - * __folio_split: split a folio at @split_at to a @new_order folio
> +/**
> + * __folio_split() - split a folio at @split_at to a @new_order folio
>    * @folio: folio to split
>    * @new_order: the order of the new folio
>    * @split_at: a page within the new folio
> @@ -3741,7 +3742,7 @@ bool uniform_split_supported(struct folio *folio, unsigned int new_order,
>    * 1. for uniform split, @lock_at points to one of @folio's subpages;
>    * 2. for buddy allocator like (non-uniform) split, @lock_at points to @folio.
>    *
> - * return: 0: successful, <0 failed (if -ENOMEM is returned, @folio might be
> + * Return: 0 - successful, <0 - failed (if -ENOMEM is returned, @folio might be
>    * split but not to @new_order, the caller needs to check)
>    */
>   static int __folio_split(struct folio *folio, unsigned int new_order,
> @@ -4130,14 +4131,13 @@ int __split_huge_page_to_list_to_order(struct page *page, struct list_head *list
>   				unmapped);
>   }
>   
> -/*
> - * folio_split: split a folio at @split_at to a @new_order folio
> +/**
> + * folio_split() - split a folio at @split_at to a @new_order folio
>    * @folio: folio to split
>    * @new_order: the order of the new folio
>    * @split_at: a page within the new folio
> - *
> - * return: 0: successful, <0 failed (if -ENOMEM is returned, @folio might be
> - * split but not to @new_order, the caller needs to check)
> + * @list: after-split folios are added to @list if not null, otherwise to LRU
> + *        list
>    *
>    * It has the same prerequisites and returns as
>    * split_huge_page_to_list_to_order().
> @@ -4151,6 +4151,9 @@ int __split_huge_page_to_list_to_order(struct page *page, struct list_head *list
>    * [order-4, {order-3}, order-3, order-5, order-6, order-7, order-8].
>    *
>    * After split, folio is left locked for caller.
> + *
> + * Return: 0 - successful, <0 - failed (if -ENOMEM is returned, @folio might be
> + * split but not to @new_order, the caller needs to check)
>    */
>   int folio_split(struct folio *folio, unsigned int new_order,
>   		struct page *split_at, struct list_head *list)



  reply	other threads:[~2025-10-30  2:31 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-30  1:40 [PATCH v4 0/3] Optimize folio split in memory failure Zi Yan
2025-10-30  1:40 ` [PATCH v4 1/3] mm/huge_memory: add split_huge_page_to_order() Zi Yan
2025-10-30  2:25   ` Lance Yang
2025-10-30  2:38   ` Barry Song
2025-10-30 12:02   ` Miaohe Lin
2025-10-31  2:32   ` Wei Yang
2025-10-31  7:58   ` David Hildenbrand
2025-10-30  1:40 ` [PATCH v4 2/3] mm/memory-failure: improve large block size folio handling Zi Yan
2025-10-30  2:29   ` Lance Yang
2025-10-30  4:00   ` Barry Song
2025-10-30 12:15   ` Miaohe Lin
2025-10-31  2:41   ` Wei Yang
2025-10-31  8:20   ` David Hildenbrand
2025-10-30  1:40 ` [PATCH v4 3/3] mm/huge_memory: fix kernel-doc comments for folio_split() and related Zi Yan
2025-10-30  2:31   ` Lance Yang [this message]
2025-10-30  4:01   ` Barry Song
2025-10-30 12:20   ` Miaohe Lin
2025-10-31  2:55   ` Wei Yang
2025-10-31 15:44     ` Zi Yan
2025-10-31  3:42 ` [PATCH v4 0/3] Optimize folio split in memory failure Andrew Morton
2025-10-31 15:42   ` Zi Yan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17dea8a6-b473-44da-82d2-d84223b7cdf1@linux.dev \
    --to=lance.yang@linux.dev \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@redhat.com \
    --cc=dev.jain@arm.com \
    --cc=jane.chu@oracle.com \
    --cc=kernel@pankajraghav.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mcgrof@kernel.org \
    --cc=nao.horiguchi@gmail.com \
    --cc=npache@redhat.com \
    --cc=richard.weiyang@gmail.com \
    --cc=ryan.roberts@arm.com \
    --cc=shy828301@gmail.com \
    --cc=willy@infradead.org \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.