diff mbox series

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

Message ID 20240307181854.138928-1-zi.yan@sent.com (mailing list archive)
State New
Headers show
Series [1/2] mm/huge_memory: check new folio order when split a folio | expand

Commit Message

Zi Yan March 7, 2024, 6:18 p.m. UTC
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(+)

Comments

Andrew Morton March 7, 2024, 8:02 p.m. UTC | #1
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.
Andrew Morton March 7, 2024, 8:03 p.m. UTC | #2
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.
Zi Yan March 7, 2024, 8:09 p.m. UTC | #3
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
diff mbox series

Patch

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");