[PATCH] migrate: Skip hwpoisoned hugetlb folios during migration

[PATCH] migrate: Skip hwpoisoned hugetlb folios during migration

[Kaitao Cheng]

From: Kaitao Cheng <chengkaitao@kylinos.cn>

Hugetlb migration does not check whether the source folio contains
hwpoisoned memory before trying to move it.  After the folio is unmapped,
the move path can reach hugetlbfs_migrate_folio() and then
migrate_huge_page_move_mapping(), which copies the source folio into the
new folio.

That copy uses folio_mc_copy(), so architectures with recoverable
machine-check copy support can fail the copy with -EHWPOISON.  However,
there is no reason to attempt the move once the source folio is already
known to contain poisoned memory.  Architectures without such copy_mc
support also fall back to a normal copy, which can consume the poison.

Check folio_contain_hwpoisoned_page() after locking the source hugetlb
folio and fail the migration with -EHWPOISON before unmapping or copying
it.  This covers both a hwpoisoned hugetlb head folio and large folios
that only have the has_hwpoisoned summary flag set.

Fixes: 290408d4a250 ("hugetlb: hugepage migration core")
Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn>
---
 mm/migrate.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/mm/migrate.c b/mm/migrate.c
index 49e10feeb094..ac12e9aeb05f 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1510,6 +1510,11 @@ static int unmap_and_move_huge_page(new_folio_t get_new_folio,
 		goto out_unlock;
 	}
 
+	if (unlikely(folio_contain_hwpoisoned_page(src))) {
+		rc = -EHWPOISON;
+		goto out_unlock;
+	}
+
 	if (folio_test_anon(src))
 		anon_vma = folio_get_anon_vma(src);
 
-- 
2.43.0

Re: [PATCH] migrate: Skip hwpoisoned hugetlb folios during migration

[Andrew Morton]

On Wed,  1 Jul 2026 18:55:44 +0800 Kaitao Cheng <kaitao.cheng@linux.dev> wrote:

> Hugetlb migration does not check whether the source folio contains
> hwpoisoned memory before trying to move it.  After the folio is unmapped,
> the move path can reach hugetlbfs_migrate_folio() and then
> migrate_huge_page_move_mapping(), which copies the source folio into the
> new folio.
> 
> That copy uses folio_mc_copy(), so architectures with recoverable
> machine-check copy support can fail the copy with -EHWPOISON.  However,
> there is no reason to attempt the move once the source folio is already
> known to contain poisoned memory.  Architectures without such copy_mc
> support also fall back to a normal copy, which can consume the poison.
> 
> Check folio_contain_hwpoisoned_page() after locking the source hugetlb
> folio and fail the migration with -EHWPOISON before unmapping or copying
> it.  This covers both a hwpoisoned hugetlb head folio and large folios
> that only have the has_hwpoisoned summary flag set.

Thanks.  I'll await reviewer input on this.

AI review suggests that a couple of other places may have the same
issue:

	https://sashiko.dev/#/patchset/20260701105544.97059-1-kaitao.cheng@linux.dev