From: yangge1116@126.com
To: akpm@linux-foundation.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
21cnbao@gmail.com, david@redhat.com,
baolin.wang@linux.alibaba.com, liuzixing@hygon.cn,
yangge <yangge1116@126.com>
Subject: [PATCH] mm/hugetlb: prevent reuse of isolated free hugepages
Date: Fri, 10 Jan 2025 10:56:06 +0800 [thread overview]
Message-ID: <1736477766-23525-1-git-send-email-yangge1116@126.com> (raw)
From: yangge <yangge1116@126.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@126.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
next reply other threads:[~2025-01-10 2:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-10 2:56 yangge1116 [this message]
2025-01-10 8:14 ` David Hildenbrand
2025-01-11 1:45 ` Andrew Morton
2025-01-11 8:00 ` Ge Yang
2025-01-11 8:00 ` Ge Yang
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=1736477766-23525-1-git-send-email-yangge1116@126.com \
--to=yangge1116@126.com \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liuzixing@hygon.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox