From: sashiko-bot@kernel.org
To: "Mark Bundschuh" <mkbund@amazon.com>
Cc: sashal@kernel.org, linux-mm@kvack.org, david@kernel.org,
yangge <yangge1116@126.com>,
"Baolin Wang" <baolin.wang@linux.alibaba.com>,
"Barry Song" <21cnbao@gmail.com>,
"David Hildenbrand" <david@redhat.com>,
"SeongJae Park" <sj@kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [PATCH v2 5.15 1/2] mm: replace free hugepage folios after migration
Date: Sat, 07 Nov 2026 22:05:27 +0000 [thread overview]
Message-ID: <sashiko-outbox-203352@kernel.org> (raw)
In-Reply-To: <20261106220445.2859944-2-mkbund@amazon.com>
Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [High] mm/hugetlb: isolated free pages in free_huge_pages break
reservations and offline
- [Low] mm: missing Fixes trailer on commit fixing hugetlb migration in
alloc_contig_range()
--
commit d4646288ad2f50427e782b8be06fdbc2d46b6d5b
Author: yangge <yangge1116@126.com>
mm: replace free hugepage folios after migration
This commit adds replace_free_hugepage_folios() after migrating in-use
hugetlb pages in alloc_contig_range() and skips MIGRATE_ISOLATE pages in
dequeue_huge_page_node_exact() so freed hugepages in the isolated range are
returned to the buddy allocator instead of being reused from the hugetlb
pool.
Link: https://lkml.kernel.org/r/1734503588-16254-1-git-send-email-yangge1116@126.com
Link: https://lkml.kernel.org/r/1736582300-11364-1-git-send-email-yangge1116@126.com
[Severity: Low]
In the commit message, this is a bug fix for migrating in-use hugetlb pages
in alloc_contig_range(). Should it include:
Fixes: ae37c7ff79f1 ("mm: make alloc_contig_range handle in-use hugetlb pages")
[Severity: High]
In mm/hugetlb.c at line 1099, does skipping MIGRATE_ISOLATE pages in
dequeue_huge_page_node_exact() while still counting them in
h->free_huge_pages allow migration to consume non-isolated free pages
backing h->resv_huge_pages?
When an in-use hugepage inside an isolated range (from offline_pages() or
alloc_contig_range()) is migrated and freed back to h->hugepage_freelists,
it remains counted in h->free_huge_pages. On the next hugepage migration,
alloc_huge_page_nodemask() (mm/hugetlb.c, line 2184) sees
h->free_huge_pages - h->resv_huge_pages > 0, and
dequeue_huge_page_node_exact() skips the isolated free page and dequeues a
non-isolated free page that was needed to back h->resv_huge_pages.
Once the free pages backing h->resv_huge_pages have been swapped into the
MIGRATE_ISOLATE range (or accounted as available by gather_surplus_pages()
at mm/hugetlb.c, line 2231), dissolve_free_huge_page() (mm/hugetlb.c, line
1971) hits h->free_huge_pages - h->resv_huge_pages == 0 and fails
offline_pages() with -EBUSY after already shrinking h->max_huge_pages. In
addition, page faults on reserved hugetlb mappings fail in
alloc_huge_page() (mm/hugetlb.c, line 2836) with -ENOSPC (delivering SIGBUS)
when dequeue_huge_page_vma() skips the isolated pages and surplus allocation
is disallowed (such as when nr_overcommit_huge_pages is 0).
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261106220445.2859944-1-mkbund@amazon.com?part=1
next prev parent reply other threads:[~2026-11-07 22:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 7:02 [PATCH 5.15] mm: replace free hugepage folios after migration Mark Bundschuh
2026-11-06 7:03 ` sashiko-bot
2026-11-06 7:46 ` David Hildenbrand (Arm)
2026-11-06 22:04 ` [PATCH v2 5.15 0/2] " Mark Bundschuh
2026-11-06 22:04 ` [PATCH v2 5.15 1/2] " Mark Bundschuh
2026-11-07 22:05 ` sashiko-bot [this message]
2026-11-06 22:04 ` [PATCH v2 5.15 2/2] mm/hugetlb: fix kernel NULL pointer dereference when replacing free hugetlb folios Mark Bundschuh
2026-11-07 22:05 ` sashiko-bot
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=sashiko-outbox-203352@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=david@redhat.com \
--cc=linux-mm@kvack.org \
--cc=mkbund@amazon.com \
--cc=sashal@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sj@kernel.org \
--cc=yangge1116@126.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.