From: Breno Leitao <leitao@debian.org>
To: Miaohe Lin <linmiaohe@huawei.com>,
Naoya Horiguchi <nao.horiguchi@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, Breno Leitao <leitao@debian.org>,
kernel-team@meta.com
Subject: [PATCH v4 2/3] mm/memory-failure: add panic option for unrecoverable pages
Date: Wed, 15 Apr 2026 05:55:01 -0700 [thread overview]
Message-ID: <20260415-ecc_panic-v4-2-2d0277f8f601@debian.org> (raw)
In-Reply-To: <20260415-ecc_panic-v4-0-2d0277f8f601@debian.org>
Add a sysctl panic_on_unrecoverable_memory_failure that triggers a
kernel panic when memory_failure() encounters pages that cannot be
recovered. This provides a clean crash with useful debug information
rather than allowing silent data corruption.
The panic is triggered for three categories of unrecoverable failures,
all requiring result == MF_IGNORED:
- MF_MSG_KERNEL: reserved pages identified via PageReserved.
- MF_MSG_KERNEL_HIGH_ORDER: pages with refcount 0 that are not in the
buddy allocator (e.g., tail pages of high-order kernel allocations).
A TOCTOU race between get_hwpoison_page() and is_free_buddy_page()
is possible when CONFIG_DEBUG_VM is disabled, since check_new_pages()
is gated by is_check_pages_enabled() and becomes a no-op. Panicking
is still correct: the physical memory has a hardware error regardless
of who allocated the page.
- MF_MSG_UNKNOWN: pages that do not match any known recoverable state
in error_states[]. A theoretical false positive from concurrent LRU
isolation is mitigated by identify_page_state()'s two-pass design
which rechecks using saved page_flags.
MF_MSG_GET_HWPOISON is intentionally excluded: it covers both
non-reserved kernel memory (SLAB/SLUB, vmalloc, kernel stacks, page
tables) and transient refcount races, so panicking would risk false
positives.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
mm/memory-failure.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 81 insertions(+)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 7b67e43dafbd1..311344f332449 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,
}
};
@@ -1281,6 +1292,59 @@ static void update_per_node_mf_stats(unsigned long pfn,
++mf_stats->total;
}
+/*
+ * Determine whether to panic on an unrecoverable memory failure.
+ *
+ * Design rationale: This design opts for immediate panic on kernel memory
+ * failures, capturing clean crashes rather than random crashes on MF_IGNORED
+ * pages.
+ *
+ * This panics on three categories of failures (all requiring result ==
+ * MF_IGNORED, meaning the page was not recovered):
+ *
+ * - MF_MSG_KERNEL: Reserved pages (identified via PageReserved) that belong
+ * to the kernel and cannot be recovered.
+ *
+ * - MF_MSG_KERNEL_HIGH_ORDER: Pages that get_hwpoison_page() observed as free
+ * (refcount 0) but are not in the buddy allocator. These are kernel pages
+ * in a transient state between allocation and freeing. A TOCTOU race
+ * (page allocated between get_hwpoison_page() and is_free_buddy_page())
+ * is possible when CONFIG_DEBUG_VM is disabled, since check_new_pages()
+ * is gated by is_check_pages_enabled() and becomes a no-op. However,
+ * panicking is still correct in this case: the physical memory has a
+ * hardware error, so an allocated hwpoisoned page is unrecoverable.
+ *
+ * - MF_MSG_UNKNOWN: Pages that reached identify_page_state() but did not
+ * match any known recoverable state in error_states[]. This is the
+ * catch-all for pages whose flags do not indicate a recoverable user or
+ * cache page (no LRU, no swapcache, no mlock, etc). A theoretical false
+ * positive exists if concurrent LRU isolation clears PG_lru between
+ * folio_lock() and saving page_flags, but this window is very narrow and
+ * mitigated by identify_page_state()'s two-pass design which rechecks
+ * using saved page_flags.
+ *
+ * Pages intentionally NOT included:
+ * - MF_MSG_GET_HWPOISON: get_hwpoison_page() failure on non-reserved pages.
+ * This includes dynamically allocated kernel memory (SLAB/SLUB, vmalloc,
+ * kernel stacks, page tables) which are not PageReserved and fail
+ * get_hwpoison_page() with -EBUSY/-EIO. These share the return path with
+ * transient refcount races, so panicking here would risk false positives.
+ *
+ * Note: Some transient races in the buddy allocator path are mitigated by
+ * memory_failure()'s retry mechanism. When take_page_off_buddy() fails,
+ * the code clears PageHWPoison and retries the entire memory_failure()
+ * flow, allowing pages to be properly reclassified with updated flags.
+ */
+static bool panic_on_unrecoverable_mf(enum mf_action_page_type type,
+ enum mf_result result)
+{
+ return sysctl_panic_on_unrecoverable_mf &&
+ result == MF_IGNORED &&
+ (type == MF_MSG_KERNEL ||
+ type == MF_MSG_KERNEL_HIGH_ORDER ||
+ type == MF_MSG_UNKNOWN);
+}
+
/*
* "Dirty/Clean" indication is not 100% accurate due to the possibility of
* setting PG_dirty outside page lock. See also comment above set_page_dirty().
@@ -1298,6 +1362,9 @@ 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 (panic_on_unrecoverable_mf(type, result))
+ panic("Memory failure: %#lx: unrecoverable page", pfn);
+
return (result == MF_RECOVERED || result == MF_DELAYED) ? 0 : -EBUSY;
}
@@ -2428,6 +2495,20 @@ int memory_failure(unsigned long pfn, int flags)
}
res = action_result(pfn, MF_MSG_BUDDY, res);
} else {
+ /*
+ * The page has refcount 0 but is not in the buddy
+ * allocator — it is a non-compound high-order kernel
+ * page (e.g., a tail page of a high-order allocation).
+ *
+ * A TOCTOU race where the page transitions from
+ * free-buddy to allocated between get_hwpoison_page()
+ * and is_free_buddy_page() is possible when
+ * CONFIG_DEBUG_VM is disabled (check_new_pages() is
+ * gated by is_check_pages_enabled() and becomes a
+ * no-op). Panicking is still correct: the physical
+ * memory has a hardware error regardless of who
+ * allocated the page.
+ */
res = action_result(pfn, MF_MSG_KERNEL_HIGH_ORDER, MF_IGNORED);
}
goto unlock_mutex;
--
2.52.0
next prev parent reply other threads:[~2026-04-15 12:55 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 12:54 [PATCH v4 0/3] mm/memory-failure: add panic option for unrecoverable pages Breno Leitao
2026-04-15 12:55 ` [PATCH v4 1/3] mm/memory-failure: report MF_MSG_KERNEL for reserved pages Breno Leitao
2026-04-22 2:50 ` Miaohe Lin
2026-04-15 12:55 ` Breno Leitao [this message]
2026-04-22 3:36 ` [PATCH v4 2/3] mm/memory-failure: add panic option for unrecoverable pages Miaohe Lin
2026-04-22 15:21 ` Breno Leitao
2026-04-23 2:38 ` Miaohe Lin
2026-04-24 12:01 ` Breno Leitao
2026-04-27 2:44 ` Miaohe Lin
2026-04-27 14:49 ` Breno Leitao
2026-04-28 2:12 ` Miaohe Lin
2026-04-15 12:55 ` [PATCH v4 3/3] Documentation: document panic_on_unrecoverable_memory_failure sysctl Breno Leitao
2026-04-22 3:43 ` Miaohe Lin
2026-04-22 15:23 ` Breno Leitao
2026-04-23 2:05 ` Miaohe Lin
2026-04-15 20:56 ` [PATCH v4 0/3] mm/memory-failure: add panic option for unrecoverable pages Jiaqi Yan
2026-04-16 15:32 ` Breno Leitao
2026-04-16 16:26 ` Jiaqi Yan
2026-04-17 9:10 ` Breno Leitao
2026-04-18 0:18 ` Jiaqi Yan
2026-04-22 2:49 ` Miaohe Lin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260415-ecc_panic-v4-2-2d0277f8f601@debian.org \
--to=leitao@debian.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=kernel-team@meta.com \
--cc=linmiaohe@huawei.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=nao.horiguchi@gmail.com \
--cc=rppt@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.