[PATCH v2] mm/migrate: Avoid copying hwpoisoned folios during migration

[PATCH v2] mm/migrate: Avoid copying hwpoisoned folios during migration

[Kaitao Cheng]

From: Kaitao Cheng <chengkaitao@kylinos.cn>

The generic folio migration path can copy the source folio after it has
been unmapped.  For normal and THP folios this goes through
move_to_new_folio(), then the filesystem or anonymous migration callback,
and commonly reaches folio_mc_copy().

folio_mc_copy() uses copy_mc_highpage(), but architectures without
copy_mc_to_kernel support fall back to copy_highpage().  If the source
folio already contains a hwpoisoned page, a normal copy can consume the
poisoned memory and trigger a synchronous machine check.

Check whether the source folio contains a hwpoisoned page in
move_to_new_folio(), before invoking any migration callback that may copy
from it.  Return -EHWPOISON so the folio is treated as a permanent
migration failure instead of being copied or retried as a transient
failure.

Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn>
---
Changes in v2:
- Move the hwpoison check from the hugetlb-specific migration path to
  move_to_new_folio(), so the normal and THP migration paths are covered.

Link to v1:
https://lore.kernel.org/all/20260701105544.97059-1-kaitao.cheng@linux.dev/
---
 mm/migrate.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/migrate.c b/mm/migrate.c
index 7301e424f8d8..f4f55a6fc23c 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1098,6 +1098,9 @@ static int move_to_new_folio(struct folio *dst, struct folio *src,
 	VM_BUG_ON_FOLIO(!folio_test_locked(src), src);
 	VM_BUG_ON_FOLIO(!folio_test_locked(dst), dst);
 
+	if (unlikely(folio_contain_hwpoisoned_page(src)))
+		return -EHWPOISON;
+
 	if (!mapping)
 		rc = migrate_folio(mapping, dst, src, mode);
 	else if (mapping_inaccessible(mapping))
-- 
2.50.1 (Apple Git-155)

Re: [PATCH v2] mm/migrate: Avoid copying hwpoisoned folios during migration

[David Hildenbrand (Arm)]

On 7/7/26 11:01, Kaitao Cheng wrote:
> From: Kaitao Cheng <chengkaitao@kylinos.cn>
> 
> The generic folio migration path can copy the source folio after it has
> been unmapped.  For normal and THP folios this goes through
> move_to_new_folio(), then the filesystem or anonymous migration callback,
> and commonly reaches folio_mc_copy().
> 
> folio_mc_copy() uses copy_mc_highpage(), but architectures without
> copy_mc_to_kernel support fall back to copy_highpage().  If the source
> folio already contains a hwpoisoned page, a normal copy can consume the
> poisoned memory and trigger a synchronous machine check.

Well, but the code can still race with memory_failure() IIUC, so it's not really
safe either?

-- 
Cheers,

David

Re: [PATCH v2] mm/migrate: Avoid copying hwpoisoned folios during migration

[Huang, Ying]

"David Hildenbrand (Arm)" <david@kernel.org> writes:

> On 7/7/26 11:01, Kaitao Cheng wrote:
>> From: Kaitao Cheng <chengkaitao@kylinos.cn>
>> 
>> The generic folio migration path can copy the source folio after it has
>> been unmapped.  For normal and THP folios this goes through
>> move_to_new_folio(), then the filesystem or anonymous migration callback,
>> and commonly reaches folio_mc_copy().
>> 
>> folio_mc_copy() uses copy_mc_highpage(), but architectures without
>> copy_mc_to_kernel support fall back to copy_highpage().  If the source
>> folio already contains a hwpoisoned page, a normal copy can consume the
>> poisoned memory and trigger a synchronous machine check.
>
> Well, but the code can still race with memory_failure() IIUC, so it's not really
> safe either?

Yes.  So the better way to fix this is to implement copy_mc_to_kernel()
for the target architectures, or to implement the trick in the fallback?

---
Best Regards,
Huang, Ying