Re: [PATCH 0/4] vmcore-tasks: export per-task metadata to vmcoreinfo

From: Simon Horman

Date: Mon Jul 20 2026 - 05:33:19 EST


On Tue, Jul 07, 2026 at 09:21:58AM +0300, Mike Rapoport wrote:
> (adding new Baoquan's email)
>
> Hi Pnina,
> On Tue, Jun 23, 2026 at 12:14:26AM +0300, Pnina Feder wrote:
> > This series extends vmcoreinfo with struct offsets and sizes needed by
> > the vmcore-tasks userspace tool to extract per-task state from a vmcore
> > dump without requiring kernel debug symbols (DWARF/BTF).
> >
> > The vmcore-tasks tool reads /proc/vmcore (or a saved vmcore file) and
> > reconstructs, for each task:
> > - task name, pid, state, flags
> > - VMA list (start, end, flags, backing file)
> > - user register state (saved on the kernel stack at kernel entry)
> > - user-space backtrace with VMA/filename mapping
> > - kernel dmesg buffer
> >
> > This provides a lightweight post-mortem crash analysis capability for
> > production environments where full debug info (DWARF/BTF) is not
> > available.
> >
> > The companion userspace tool is submitted to kexec-tools:
> > https://lore.kernel.org/all/20260622205550.1087163-1-pnina.feder@xxxxxxxxxxxx/
>
> Sorry for the delay, this fell between the cracks somehow.
>
> The kernel side looks fine overall, but to merge it there should be an
> agreement from the userspace side maintainers that vmcore-tasks is
> something they are wishing to accept.

Hi Mike, all,

Sorry for the extended delay.

I will send some minor feedback to the user-space tool patchset
but overall, yes, this is something I would be happy to accept.

I don't want to create a chicken-and-egg type problem here.
But it's probably worth mentioning that usually features
hit the kernel before the corresponding code is accepted
into kexec-tools.

Let me know how you would like to proceed.