Re: [PATCH v3] tools/mm: add hwpoison-panic tool

[SJ Park <sj@kernel.org>]

On Thu, 13 Aug 2026 04:45:15 -0700 Breno Leitao <leitao@debian.org> wrote:

> Add a tool that enables the vm.panic_on_unrecoverable_memory_failure
> sysctl, picks a kernel-owned PFN and writes its physical address to
> hard_offline_page.  Three page kinds are selectable with -k: rodata
> (default), slab or pgtable. In all cases the host should panic.
> 
> Example:
> 
>         # ./hwpoison-panic -k slab --yes-panic-my-kernel
>         injecting hwpoison at phys 0x100032000 (pfn 0x100032, kind=slab)
>         expecting kernel panic: 'Memory failure: <pfn>: unrecoverable page'

Too trivial nit, but I couldn't resist.  Why print '<pfn>' instead of the real
pfn value, while we know it?

> 
> In dmesg, you will see:
> 
>         Memory failure: 0x100032: unhandlable page.
>         Memory failure: 0x100032: recovery action for reserved kernel page: Ignored
>         Kernel panic - not syncing: Memory failure: 0x100032: unrecoverable page
> 
> This lives in tools/mm rather than selftests/mm because every successful
> run crashes the machine, which is not something to run from CI.
> 
> The --yes-panic-my-kernel argument is required so an accidental
> invocation does not take the box down.

Looks useful to me, thank you!

> 
> Signed-off-by: Breno Leitao <leitao@debian.org>

Reviewed-by: SJ Park <sj@kernel.org>

[...]
> +static const char *inject_hwpoison(const struct page_kind *kind,
> +				   uint64_t phys_addr, uint64_t pfn)
> +{
> +	char buf[32];
> +	int fd, len;
> +	ssize_t ret;
> +
> +	printf("injecting hwpoison at phys 0x%llx (pfn 0x%llx, kind=%s)\n",
> +	       (unsigned long long)phys_addr, (unsigned long long)pfn,
> +	       kind->name);
> +	printf("expecting kernel panic: 'Memory failure: <pfn>: unrecoverable page'\n");
> +	fflush(stdout);
> +
> +	fd = open(INJECT_PATH, O_WRONLY);
> +	if (fd < 0)
> +		return "cannot open " INJECT_PATH;
> +
> +	len = snprintf(buf, sizeof(buf), "0x%llx", (unsigned long long)phys_addr);

Yet another trivial comment.  I'm not a big fan of >80 columns lines, but I
understand there are various tastes :)


Thanks,
SJ

[...]