| Message ID | 1736477766-23525-1-git-send-email-yangge1116@126.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm/hugetlb: prevent reuse of isolated free hugepages | expand |
On 10.01.25 03:56, yangge1116@126.com wrote: > 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. s/slove/solve/ s/proble/problem/ > > Link: https://lore.kernel.org/lkml/1734503588-16254-1-git-send-email-yangge1116@126.com/ > Fixes: 08d312ee4c0a ("mm: replace free hugepage folios after migration") The commit id is not stable yet. $ git tag --contains 08d312ee4c0a mm-everything-2025-01-09-06-44 next-20250110 We should squash this into the original fix. Can you resend the whole thing and merge the patch descriptions? > 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); Sorry for not getting back to your previous mail, this week was a bit crazy. This will work reliably if the huge page does not span more than a single page block. Assuming it would span multiple ones, we might have only isolated the last etc. pageblock. For the common cases it might do, but not for all cases unfortunately (especially not gigantic pages, but I recall we skip them during alloc_contig_pages(); I recall some oddities on ppc even without gigantic pages involved). One option would be to stare at all involved pageblocks, although a bit nasty ... let me think about this.
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);