From: yangge <yangge1116@xxxxxxx> 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@xxxxxxx/ Fixes: 08d312ee4c0a ("mm: replace free hugepage folios after migration") Signed-off-by: yangge <yangge1116@xxxxxxx> --- 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
