[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:

> Date: Wed,  1 Jul 2026 18:55:44 +0800

Well.

> 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.

As always: please provide a description of the userspace-visible
runtime effects of the bug.

Even better if you can present a reproducer.

> Fixes: 290408d4a250 ("hugetlb: hugepage migration core")

Oct, 2010.  So I'm assuming this isn't super-urgent.

otoh, now it's out there and known about, perhaps Bad Guys can find a
way of triggering this, so the urgency becomes higher.


Anyway, please consider the Sashiko report
(https://sashiko.dev/#/patchset/20260701105544.97059-1-kaitao.cheng@linux.dev)
then update the changelog with the above info.  Decide whether we
should cc:stable (and describe why) then resend?

Thanks.

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

[Kaitao Cheng]

在 2026/9/3 10:34, Andrew Morton 写道:
> On Wed,  1 Jul 2026 18:55:44 +0800 Kaitao Cheng <kaitao.cheng@linux.dev> wrote:
> 
>> Date: Wed,  1 Jul 2026 18:55:44 +0800
> 
> Well.
> 
>> 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.
> 
> As always: please provide a description of the userspace-visible
> runtime effects of the bug.
> 
> Even better if you can present a reproducer.
> 
>> Fixes: 290408d4a250 ("hugetlb: hugepage migration core")
> 
> Oct, 2010.  So I'm assuming this isn't super-urgent.
> 
> otoh, now it's out there and known about, perhaps Bad Guys can find a
> way of triggering this, so the urgency becomes higher.

In the subsequent discussion of the v2 patch, it became clear that the
current fix can only narrow the race window and cannot fully resolve
the issue. I do not currently have a complete solution in mind, so this
issue is blocked for now.

v2: https://lore.kernel.org/all/20260707090136.52904-1-kaitao.cheng@linux.dev/#t

> Anyway, please consider the Sashiko report
> (https://sashiko.dev/#/patchset/20260701105544.97059-1-kaitao.cheng@linux.dev)
> then update the changelog with the above info.  Decide whether we
> should cc:stable (and describe why) then resend?
> 
> Thanks.

-- 
Thanks
Kaitao Cheng