From: "David Hildenbrand (Red Hat)" <david@kernel.org>
To: Barry Song <21cnbao@gmail.com>, Zi Yan <ziy@nvidia.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Nico Pache <npache@redhat.com>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Lance Yang <lance.yang@linux.dev>,
Miaohe Lin <linmiaohe@huawei.com>,
Naoya Horiguchi <nao.horiguchi@gmail.com>,
Wei Yang <richard.weiyang@gmail.com>,
Balbir Singh <balbirs@nvidia.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/4] mm/huge_memory: change folio_split_supported() to folio_check_splittable()
Date: Mon, 24 Nov 2025 11:33:47 +0100 [thread overview]
Message-ID: <60d27f00-20ca-4a58-9d32-ffbe55f69a1d@kernel.org> (raw)
In-Reply-To: <CAGsJ_4wyL9TZr141emBOBTKhN7oEJjeA7kFxhoBbi-cme-5tKg@mail.gmail.com>
On 11/23/25 19:38, Barry Song wrote:
> Hi Zi Yan,
>
> Thanks for the nice cleanup.
>
> On Sat, Nov 22, 2025 at 10:55 AM Zi Yan <ziy@nvidia.com> wrote:
>>
>> folio_split_supported() used in try_folio_split_to_order() requires
>> folio->mapping to be non NULL, but current try_folio_split_to_order() does
>> not check it. There is no issue in the current code, since
>> try_folio_split_to_order() is only used in truncate_inode_partial_folio(),
>> where folio->mapping is not NULL.
>>
>> To prevent future misuse, move folio->mapping NULL check (i.e., folio is
>> truncated) into folio_split_supported(). Since folio->mapping NULL check
>> returns -EBUSY and folio_split_supported() == false means -EINVAL, change
>> folio_split_supported() return type from bool to int and return error
>> numbers accordingly. Rename folio_split_supported() to
>> folio_check_splittable() to match the return type change.
>>
>> While at it, move is_huge_zero_folio() check and folio_test_writeback()
>> check into folio_check_splittable() and add kernel-doc.
>>
>> Signed-off-by: Zi Yan <ziy@nvidia.com>
>> ---
>> include/linux/huge_mm.h | 10 ++++--
>> mm/huge_memory.c | 74 +++++++++++++++++++++++++----------------
>> 2 files changed, 53 insertions(+), 31 deletions(-)
>>
>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>> index 1d439de1ca2c..97686fb46e30 100644
>> --- a/include/linux/huge_mm.h
>> +++ b/include/linux/huge_mm.h
>> @@ -375,8 +375,8 @@ int __split_huge_page_to_list_to_order(struct page *page, struct list_head *list
>> int folio_split_unmapped(struct folio *folio, unsigned int new_order);
>> int min_order_for_split(struct folio *folio);
>> int split_folio_to_list(struct folio *folio, struct list_head *list);
>> -bool folio_split_supported(struct folio *folio, unsigned int new_order,
>> - enum split_type split_type, bool warns);
>> +int folio_check_splittable(struct folio *folio, unsigned int new_order,
>> + enum split_type split_type, bool warns);
>
>
> It feels a bit odd to have a warns parameter here, especially given that it's
> a bool. I understand that in one case we're only checking whether a split is
> possible, without actually performing it. In the other case, we are performing
> the split, so we must confirm it's valid — otherwise it's a bug.
>
> Could we rename split_type to something more like gfp_flags, where we have
> variants such as __GFP_NOWARN or something similar? That would make the code
> much more readable.
Could we get rid of the "warns" parameter and simply always do a
pr_warn_once()?
As an alternative, simply move the warning to the single caller
VM_WARN_ONCE(ret == -EINVAL, "Tried to split an unsplittable folio");
--
Cheers
David
next prev parent reply other threads:[~2025-11-24 10:33 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-22 2:55 [PATCH v2 0/4] Improve folio split related functions Zi Yan
2025-11-22 2:55 ` [PATCH v2 1/4] mm/huge_memory: change folio_split_supported() to folio_check_splittable() Zi Yan
2025-11-23 1:50 ` Wei Yang
2025-11-23 18:38 ` Barry Song
2025-11-24 10:33 ` David Hildenbrand (Red Hat) [this message]
2025-11-24 16:38 ` Zi Yan
2025-11-25 8:58 ` David Hildenbrand (Red Hat)
2025-11-25 17:44 ` Andrew Morton
2025-11-22 2:55 ` [PATCH v2 2/4] mm/huge_memory: replace can_split_folio() with direct refcount calculation Zi Yan
2025-11-23 1:51 ` Wei Yang
2025-11-24 10:41 ` David Hildenbrand (Red Hat)
2025-11-24 17:05 ` Zi Yan
2025-11-24 19:22 ` David Hildenbrand (Red Hat)
2025-11-24 21:08 ` Zi Yan
2025-11-25 8:52 ` David Hildenbrand (Red Hat)
2025-11-25 15:55 ` Zi Yan
2025-11-25 9:10 ` Miaohe Lin
2025-11-25 9:34 ` David Hildenbrand (Red Hat)
2025-11-24 22:14 ` Balbir Singh
2025-11-25 8:55 ` David Hildenbrand (Red Hat)
2025-11-25 15:41 ` Zi Yan
2025-11-22 2:55 ` [PATCH v2 3/4] mm/huge_memory: make min_order_for_split() always return an order Zi Yan
2025-11-23 1:53 ` Wei Yang
2025-11-24 10:43 ` David Hildenbrand (Red Hat)
2025-11-24 15:18 ` Lorenzo Stoakes
2025-11-24 17:11 ` Zi Yan
2025-11-22 2:55 ` [PATCH v2 4/4] mm/huge_memory: fix folio split stats counting Zi Yan
2025-11-23 1:56 ` Wei Yang
2025-11-24 10:45 ` David Hildenbrand (Red Hat)
2025-11-24 17:23 ` Zi Yan
2025-11-24 15:21 ` Lorenzo Stoakes
2025-11-24 17:29 ` 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=60d27f00-20ca-4a58-9d32-ffbe55f69a1d@kernel.org \
--to=david@kernel.org \
--cc=21cnbao@gmail.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=balbirs@nvidia.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=dev.jain@arm.com \
--cc=lance.yang@linux.dev \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=nao.horiguchi@gmail.com \
--cc=npache@redhat.com \
--cc=richard.weiyang@gmail.com \
--cc=ryan.roberts@arm.com \
--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.