The folio migration is widely used in kernel, memory compaction, memory
hotplug, soft offline page, numa balance, memory demote/promotion, etc,
but once access a poisoned source folio when migrating, the kernel will
panic.
There is a mechanism in the kernel to recover from uncorrectable memory
errors, ARCH_HAS_COPY_MC(eg, Machine Check Safe Memory Copy on x86), which
is already used in NVDIMM or core-mm paths(eg, CoW, khugepaged, coredump,
ksm copy), see copy_mc_to_{user,kernel}, copy_mc_{user_}highpage callers.
This series of patches provide the recovery mechanism from folio copy for
the widely used folio migration. Please note, because folio migration is
no guarantee of success, so we could chose to make folio migration tolerant
of memory failures, adding folio_mc_copy() which is a #MC versions of
folio_copy(), once accessing a poisoned source folio, we could return error
and make the folio migration fail, and this could avoid the similar panic
shown below.
CPU: 1 PID: 88343 Comm: test_softofflin Kdump: loaded Not tainted 6.6.0
pc : copy_page+0x10/0xc0
lr : copy_highpage+0x38/0x50
...
Call trace:
copy_page+0x10/0xc0
folio_copy+0x78/0x90
migrate_folio_extra+0x54/0xa0
move_to_new_folio+0xd8/0x1f0
migrate_folio_move+0xb8/0x300
migrate_pages_batch+0x528/0x788
migrate_pages_sync+0x8c/0x258
migrate_pages+0x440/0x528
soft_offline_in_use_page+0x2ec/0x3c0
soft_offline_page+0x238/0x310
soft_offline_page_store+0x6c/0xc0
dev_attr_store+0x20/0x40
sysfs_kf_write+0x4c/0x68
kernfs_fop_write_iter+0x130/0x1c8
new_sync_write+0xa4/0x138
vfs_write+0x238/0x2d8
ksys_write+0x74/0x110
v5:
- revert to folio_ref_freeze() under xas_lock_irq(), since Hugh Dickins
found issue when move freeze folio out of xas_lock_irq, thanks, and the
fix patch[1] is same as my RFC version[2], so let's turn back to the old
way, patch 2~4 are changed so drop the RB from v4.
- revert v4 and rebased on next-20240625
[1] https://lore.kernel.org/linux-mm/07edaae7-ea5d-b6ae-3a10-f611946f9688@xxxxxxxxxx/
[2] https://lore.kernel.org/linux-mm/20240129070934.3717659-7-wangkefeng.wang@xxxxxxxxxx/
v4:
- return -EHWPOISON instead of -EFAULT in folio_mc_copy() and omit a ret
variable, per Jane and Lance
- return what folio_mc_copy() returns from callers, per Jane
- move memory_failure_queue() into copy_mc_[user_]highpage() instead of
calling it after each copy_mc_[user]_highpage caller, which avoids
re-using the poisoned page, per Luck, Tony
v3:
- only folio migrate recover support part since the cleanup part
has been merged to mm-unstable
- don't introduce new folio_refs_check_and_freeze(), just move
the check and freeze folio out, also update changelog 'mm:
migrate: split folio_migrate_mapping()'
- reorder patches and rebased on next-20240528
- https://lore.kernel.org/linux-mm/20240528134513.2283548-1-wangkefeng.wang@xxxxxxxxxx/
Kefeng Wang (6):
mm: move memory_failure_queue() into copy_mc_[user]_highpage()
mm: add folio_mc_copy()
mm: migrate: split folio_migrate_mapping()
mm: migrate: support poisoned recover from migrate folio
fs: hugetlbfs: support poisoned recover from hugetlbfs_migrate_folio()
mm: migrate: remove folio_migrate_copy()
fs/aio.c | 3 +-
fs/hugetlbfs/inode.c | 2 +-
include/linux/highmem.h | 6 ++++
include/linux/migrate.h | 1 -
include/linux/mm.h | 1 +
mm/ksm.c | 1 -
mm/memory.c | 12 ++-----
mm/migrate.c | 71 ++++++++++++++++++++++++-----------------
mm/util.c | 17 ++++++++++
9 files changed, 72 insertions(+), 42 deletions(-)
--
2.27.0
