From: Zi Yan <[email protected]>
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/[email protected]/
Fixes: c010d47f107f ("mm: thp: split huge page to any lower order pages")
Signed-off-by: Zi Yan <[email protected]>
---
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
From: Zi Yan <[email protected]>
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/[email protected]/
Signed-off-by: Zi Yan <[email protected]>
---
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
On Thu, 7 Mar 2024 13:18:53 -0500 Zi Yan <[email protected]> wrote:
> From: Zi Yan <[email protected]>
>
> 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.
On Thu, 7 Mar 2024 13:18:53 -0500 Zi Yan <[email protected]> wrote:
> Link: https://lore.kernel.org/linux-mm/[email protected]/
Oh, there it is.
I'll change this to Reported-by: and Closes:, thanks.
On 7 Mar 2024, at 15:02, Andrew Morton wrote:
> On Thu, 7 Mar 2024 13:18:53 -0500 Zi Yan <[email protected]> wrote:
>
>> From: Zi Yan <[email protected]>
>>
>> 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