Re: [PATCH 1/2] mm/memory-failure: add panic_on_unrecoverable_memory_failure sysctl

Miaohe Lin
2026-03-30T07:55:13Z

On 2026/3/23 23:29, Breno Leitao wrote:
> When memory_failure() encounters an in-use kernel page that cannot be
> recovered (slab, page tables, kernel stacks, reserved, vmalloc, etc.),
> it currently logs MF_IGNORED and continues. This leaves corrupted data
> accessible to the kernel, risking silent data corruption or a delayed
> crash when the poisoned cache line is next accessed.
>
> For example, a multi-bit ECC error on a dentry cache slab page was
> ignored by memory_failure(), and 67 seconds later d_lookup() accessed
> the poisoned cache line, causing a synchronous external abort:
>
> [88690.479680] [Hardware Error]: error_type: 3, multi-bit ECC
> [88690.498473] Memory failure: 0x40272d: unhandlable page.
> [88690.498619] Memory failure: 0x40272d: recovery action for
> get hwpoison page: Ignored
> ...
> [88757.847126] Internal error: synchronous external abort:
> 0000000096000410 [#1] SMP
> [88758.061075] pc : d_lookup+0x5c/0x220
>
> Add a new sysctl vm.panic_on_unrecoverable_memory_failure (default 0)
> that, when set to 1, panics immediately on unrecoverable memory
> failures. This provides a clean crash dump at the time of the error
> rather than a delayed crash with potential silent corruption in between.
>
> The panic is placed in action_result() so that all call sites that log
> MF_MSG_GET_HWPOISON with MF_IGNORED are covered, including the hugetlb
> path in try_memory_failure_hugetlb().
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> mm/memory-failure.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index ee42d43613097..25bd043497195 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -74,6 +74,8 @@ static int sysctl_memory_failure_recovery __read_mostly = 1;
>
> static int sysctl_enable_soft_offline __read_mostly = 1;
>
> +static int sysctl_panic_on_unrecoverable_mf __read_mostly;
> +
> atomic_long_t num_poisoned_pages __read_mostly = ATOMIC_LONG_INIT(0);
>
> static bool hw_memory_failure __read_mostly = false;
> @@ -155,6 +157,15 @@ static const struct ctl_table memory_failure_table[] = {
> .proc_handler = proc_dointvec_minmax,
> .extra1 = SYSCTL_ZERO,
> .extra2 = SYSCTL_ONE,
> + },
> + {
> + .procname = "panic_on_unrecoverable_memory_failure",
> + .data = &sysctl_panic_on_unrecoverable_mf,
> + .maxlen = sizeof(sysctl_panic_on_unrecoverable_mf),
> + .mode = 0644,
> + .proc_handler = proc_dointvec_minmax,
> + .extra1 = SYSCTL_ZERO,
> + .extra2 = SYSCTL_ONE,
> }
> };
>
> @@ -1298,6 +1309,10 @@ static int action_result(unsigned long pfn, enum mf_action_page_type type,
> pr_err("%#lx: recovery action for %s: %s\n",
> pfn, action_page_types[type], action_name[result]);
>
> + if (sysctl_panic_on_unrecoverable_mf &&
> + type == MF_MSG_GET_HWPOISON && result == MF_IGNORED)
> + panic("Memory failure: %#lx: unrecoverable page", pfn);

MF_MSG_GET_HWPOISON contains some other scenarios. For example, an isolated folio will
make get_hwpoison_page return -EIO so we will see MF_MSG_GET_HWPOISON and MF_IGNORED in
action_result. But that's recoverable if folio is used by userspace thus panic will be
unacceptable.
Will it better to check type against MF_MSG_KERNEL_HIGH_ORDER?

Thanks.
.