From: Miaohe Lin <linmiaohe@huawei.com>
To: Breno Leitao <leitao@debian.org>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
<linux-doc@vger.kernel.org>, <linux-kselftest@vger.kernel.org>,
<linux-trace-kernel@vger.kernel.org>, <kernel-team@meta.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
"Lorenzo Stoakes" <ljs@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Shuah Khan <shuah@kernel.org>,
Naoya Horiguchi <nao.horiguchi@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
"Liam R. Howlett" <liam@infradead.org>, <lance.yang@linux.dev>,
Steven Rostedt <rostedt@goodmis.org>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Subject: Re: [PATCH v10 6/6] selftests/mm: add hwpoison-panic destructive test
Date: Thu, 9 Jul 2026 11:34:05 +0800 [thread overview]
Message-ID: <ee4982bf-ff45-8f0b-3b76-7ca19228f12b@huawei.com> (raw)
In-Reply-To: <20260630-ecc_panic-v10-6-c6ed5b62eea2@debian.org>
On 2026/6/30 20:46, Breno Leitao wrote:
> Add a destructive selftest that verifies
> vm.panic_on_unrecoverable_memory_failure actually panics when a
> hwpoison error hits a kernel-owned page.
>
> Three "kinds" of kernel-owned page can be targeted, selectable via
> the script's first positional argument (default: rodata):
>
> rodata - a PG_reserved page in the kernel rodata range, sourced
> from the "Kernel rodata" sub-resource of "System RAM" in
> /proc/iomem. That entry is reported on every major
> architecture and guarantees the chosen PFN is backed by
> struct page (an online System RAM range, not a firmware
> hole), is PG_reserved, and is read-only -- so even if
> the panic fails to fire for some reason, the resulting
> PG_hwpoison marker on rodata does not corrupt writable
> kernel state.
>
> slab - a slab page found by walking /proc/kpageflags for the
> first PFN with KPF_SLAB set (and KPF_HWPOISON / KPF_NOPAGE
> / KPF_COMPOUND_TAIL clear). Exercises the get_any_page()
> path on a non PG_reserved kernel-owned page and so
> catches regressions where get_any_page() collapses
> kernel-owned pages into a transient -EIO instead of
> -ENOTRECOVERABLE.
>
> pgtable - same as slab, but the PFN is selected via KPF_PGTABLE.
>
> PageLargeKmalloc, the fourth page type matched by
> is_kernel_owned_page(), is intentionally not covered: it is a
> PAGE_TYPE_OPS flag with no /proc/kpageflags bit, so selecting such
> a PFN from userspace is not feasible. The slab and pgtable
> variants already exercise the same get_any_page() positive-check
> branch.
>
> The script enables the sysctl and writes the selected physical
> address to /sys/devices/system/memory/hard_offline_page. A
> successful run crashes the kernel with
>
> Memory failure: <pfn>: unrecoverable page
>
> A return from the inject means no panic fired. Before reporting, the
> script restores the sysctl and best-effort unpoisons the target PFN
> through the hwpoison debugfs interface (hard_offline_page() injects
> with MF_SW_SIMULATED, so the page stays unpoisonable), then re-reads
> /proc/kpageflags: a PFN that is still the kernel-owned type it selected
> is a genuine failure, while one that raced to a different type before
> the inject is skipped as inconclusive. Test outcome is therefore
> observed externally (serial console, kdump) rather than from the
> script's own exit code.
>
> The script is intentionally NOT wired into run_vmtests.sh: every
> successful run panics the kernel, which is incompatible with the
> sequential "run each category in the same VM" model that
> run_vmtests.sh assumes. It is also not registered as a TEST_PROGS /
> ksft_* wrapper so a default kselftest run does not opt itself into
> a panic. The script is meant to be executed manually inside a
> disposable VM (e.g. virtme-ng), one variant per VM boot, and
> requires RUN_DESTRUCTIVE=1 in the environment as a safety net.
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
With Mike's comment addressed:
Acked-by: Miaohe Lin <linmiaohe@huawei.com>
Thanks.
.
next prev parent reply other threads:[~2026-07-09 3:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 12:46 [PATCH v10 0/6] mm/memory-failure: add panic option for unrecoverable pages Breno Leitao
2026-06-30 12:46 ` [PATCH v10 1/6] mm/memory-failure: drop dead error_states[] entry for reserved pages Breno Leitao
2026-06-30 12:46 ` [PATCH v10 2/6] mm/memory-failure: surface unhandlable kernel pages as -ENOTRECOVERABLE Breno Leitao
2026-07-06 12:22 ` Miaohe Lin
2026-06-30 12:46 ` [PATCH v10 3/6] mm/memory-failure: report MF_MSG_KERNEL for unrecoverable kernel pages Breno Leitao
2026-06-30 12:46 ` [PATCH v10 4/6] mm/memory-failure: add panic option for unrecoverable pages Breno Leitao
2026-06-30 12:46 ` [PATCH v10 5/6] Documentation: document panic_on_unrecoverable_memory_failure sysctl Breno Leitao
2026-07-09 3:18 ` Miaohe Lin
2026-06-30 12:46 ` [PATCH v10 6/6] selftests/mm: add hwpoison-panic destructive test Breno Leitao
2026-07-04 9:31 ` Mike Rapoport
2026-07-06 16:14 ` Breno Leitao
2026-07-06 16:23 ` Mike Rapoport
2026-07-09 3:34 ` Miaohe Lin [this message]
2026-06-30 20:55 ` [PATCH v10 0/6] mm/memory-failure: add panic option for unrecoverable pages Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2026-06-26 15:33 Breno Leitao
2026-06-26 15:33 ` [PATCH v10 6/6] selftests/mm: add hwpoison-panic destructive test Breno Leitao
2026-06-27 7:52 ` Mike Rapoport
2026-06-29 15:50 ` Breno Leitao
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=ee4982bf-ff45-8f0b-3b76-7ca19228f12b@huawei.com \
--to=linmiaohe@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=kernel-team@meta.com \
--cc=lance.yang@linux.dev \
--cc=leitao@debian.org \
--cc=liam@infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=nao.horiguchi@gmail.com \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=shuah@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).