[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1736477766-23525-1-git-send-email-yangge1116@126.com>
Date: Fri, 10 Jan 2025 10:56:06 +0800
From: yangge1116@....com
To: akpm@...ux-foundation.org
Cc: linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
21cnbao@...il.com,
david@...hat.com,
baolin.wang@...ux.alibaba.com,
liuzixing@...on.cn,
yangge <yangge1116@....com>
Subject: [PATCH] mm/hugetlb: prevent reuse of isolated free hugepages
From: yangge <yangge1116@....com>
When there are free hugetlb folios in the hugetlb pool, during the
migration of in-use hugetlb folios, new folios is allocated from
the free hugetlb pool. After the migration is completed, the old
folios are released back to the free hugetlb pool. However, after
the old folios are released to the free hugetlb pool, they may be
reallocated. When replace_free_hugepage_folios() is executed later,
it cannot release these old folios back to the buddy system.
As discussed with David in [1], when alloc_contig_range() is used
to migrate multiple in-use hugetlb pages, it can lead to the issue
described above. For example:
[huge 0] [huge 1]
To migrate huge 0, we obtain huge x from the pool. After the migration
is completed, we return the now-freed huge 0 back to the pool. When
it's time to migrate huge 1, we can simply reuse the now-freed huge 0
from the pool. As a result, when replace_free_hugepage_folios() is
executed, it cannot release huge 0 back to the buddy system.
To slove the proble above, we should prevent reuse of isolated free
hugepages.
Link: https://lore.kernel.org/lkml/1734503588-16254-1-git-send-email-yangge1116@126.com/
Fixes: 08d312ee4c0a ("mm: replace free hugepage folios after migration")
Signed-off-by: yangge <yangge1116@....com>
---
mm/hugetlb.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 9a55960..e5f9999 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -48,6 +48,7 @@
#include <linux/page_owner.h>
#include "internal.h"
#include "hugetlb_vmemmap.h"
+#include <linux/page-isolation.h>
int hugetlb_max_hstate __read_mostly;
unsigned int default_hstate_idx;
@@ -1273,6 +1274,9 @@ static struct folio *dequeue_hugetlb_folio_node_exact(struct hstate *h,
if (folio_test_hwpoison(folio))
continue;
+ if (is_migrate_isolate_page(&folio->page))
+ continue;
+
list_move(&folio->lru, &h->hugepage_activelist);
folio_ref_unfreeze(folio, 1);
folio_clear_hugetlb_freed(folio);
--
2.7.4
Powered by blists - more mailing lists