mm/migrate: Avoid copying hwpoisoned folios during migration

From: Kaitao Cheng <[email protected]>

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.

---
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/[email protected]/

---
 mm/migrate.c | 3 +++
 1 file changed, 3 insertions(+)

index 7301e424f8d8..f4f55a6fc23c 100644
@@ -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)

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

Cheers,

David

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