Re: [PATCH v3] tools/mm: add hwpoison-panic tool
SJ Park <[email protected]>
| Newsgroups | org.infradead.lists.linux-riscv,org.kernel.vger.linux-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 13 Aug 2026 04:45:15 -0700 Breno Leitao <[email protected]> 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 <[email protected]> Reviewed-by: SJ Park <[email protected]> [...] > +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 [...] _______________________________________________ linux-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-riscv