[PATCH 1/2] mm/huge_memory: check new folio order when split a folio

[PATCH 1/2] mm/huge_memory: check new folio order when split a folio

[Zi Yan]

From: Zi Yan <ziy@nvidia.com>

A folio can only be split into lower orders. Check new_order to make sure
it is smaller than input folio order.

Link: https://lore.kernel.org/linux-mm/7dda9283-b437-4cf8-ab0d-83c330deb9c0@moroto.mountain/
Fixes: c010d47f107f ("mm: thp: split huge page to any lower order pages")
Signed-off-by: Zi Yan <ziy@nvidia.com>
---
 mm/huge_memory.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index a81a09236c16..57fca7bffd20 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -3052,6 +3052,9 @@ int split_huge_page_to_list_to_order(struct page *page, struct list_head *list,
 	VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio);
 	VM_BUG_ON_FOLIO(!folio_test_large(folio), folio);
 
+	if (new_order >= folio_order(folio))
+		return -EINVAL;
+
 	/* Cannot split anonymous THP to order-1 */
 	if (new_order == 1 && folio_test_anon(folio)) {
 		VM_WARN_ONCE(1, "Cannot split to order-1 folio");
-- 
2.43.0

[PATCH 2/2] mm/huge_memory: skip invalid debugfs new_order input for folio split

[Zi Yan]

From: Zi Yan <ziy@nvidia.com>

User can put arbitrary new_order via debugfs for folio split test. Although
new_order check is added to split_huge_page_to_list_order() in the prior
commit, these two additional checks can avoid unnecessary folio locking
and split_folio_to_order() calls.

Link: https://lore.kernel.org/linux-mm/7dda9283-b437-4cf8-ab0d-83c330deb9c0@moroto.mountain/
Signed-off-by: Zi Yan <ziy@nvidia.com>
---
 mm/huge_memory.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 57fca7bffd20..9859aa4f7553 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -3486,6 +3486,9 @@ static int split_huge_pages_pid(int pid, unsigned long vaddr_start,
 		if (!is_transparent_hugepage(folio))
 			goto next;
 
+		if (new_order >= folio_order(folio))
+			goto next;
+
 		total++;
 		/*
 		 * For folios with private, split_huge_page_to_list_to_order()
@@ -3553,6 +3556,9 @@ static int split_huge_pages_in_file(const char *file_path, pgoff_t off_start,
 		total++;
 		nr_pages = folio_nr_pages(folio);
 
+		if (new_order >= folio_order(folio))
+			goto next;
+
 		if (!folio_trylock(folio))
 			goto next;
 
-- 
2.43.0

Re: [PATCH 1/2] mm/huge_memory: check new folio order when split a folio

[Andrew Morton]

On Thu,  7 Mar 2024 13:18:53 -0500 Zi Yan <zi.yan@sent.com> wrote:

> From: Zi Yan <ziy@nvidia.com>
> 
> A folio can only be split into lower orders. Check new_order to make sure
> it is smaller than input folio order.

It isn't clear what's being fixed here.  Presumably something is
passing in such folios, but what and where and why and what are the
effects?

Might it be that these folios are being caused by the debugfs
interface?  Or something else?

So I'll add it, but I do think more information and context would
improve the patch, please.  Suitable Reported-by:, Closes: and Link:
tags, perhaps.

Re: [PATCH 1/2] mm/huge_memory: check new folio order when split a folio

[Zi Yan]

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

On 7 Mar 2024, at 15:02, Andrew Morton wrote:

> On Thu,  7 Mar 2024 13:18:53 -0500 Zi Yan <zi.yan@sent.com> wrote:
>
>> From: Zi Yan <ziy@nvidia.com>
>>
>> A folio can only be split into lower orders. Check new_order to make sure
>> it is smaller than input folio order.
>
> It isn't clear what's being fixed here.  Presumably something is
> passing in such folios, but what and where and why and what are the
> effects?
>
> Might it be that these folios are being caused by the debugfs
> interface?  Or something else?

Since there is no new_order checks in debugfs before, any
new_order can be passed via debugfs into
split_huge_page_to_list_to_order().

I did not explicitly mention it here as the debugfs is added in
the commit after the Fixes one.

>
> So I'll add it, but I do think more information and context would
> improve the patch, please.  Suitable Reported-by:, Closes: and Link:
> tags, perhaps.


--
Best Regards,
Yan, Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]

Re: [PATCH 1/2] mm/huge_memory: check new folio order when split a folio

[Andrew Morton]

On Thu,  7 Mar 2024 13:18:53 -0500 Zi Yan <zi.yan@sent.com> wrote:

> Link: https://lore.kernel.org/linux-mm/7dda9283-b437-4cf8-ab0d-83c330deb9c0@moroto.mountain/

Oh, there it is.

I'll change this to Reported-by: and Closes:, thanks.