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

On Fri, Jul 24, 2026 at 1:05=E2=80=AFAM Pnina Feder <[email protected]=
om> wrote:
>
> > On 07/20/26 at 10:35am, Omar Sandoval wrote:
> > > On Mon, Jul 20, 2026 at 10:40:43PM +0800, Baoquan He wrote:
> > > > On 07/20/26 at 03:43pm, Mike Rapoport wrote:
> > > > > Hi Simon,
> > > > >
> > > > > On Mon, Jul 20, 2026 at 10:19:27AM +0100, Simon Horman wrote:
> > > > > > On Tue, Jul 07, 2026 at 09:21:58AM +0300, Mike Rapoport wrote:
> > > > > > > On Tue, Jun 23, 2026 at 12:14:26AM +0300, Pnina Feder wrote:
> > > > > > > > This series extends vmcoreinfo with struct offsets and size=
s
> > > > > > > > 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 kerne=
l 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 inf=
o
> > > > > > > > (DWARF/BTF) is not available.
> > > > > > > >
> > > > > > > > The companion userspace tool is submitted to kexec-tools:
> > > > > > > >   Suspicious Link - Removed
> > > > > > >
> > > > > > > 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 th=
e
> > > > > > kernel before the corresponding code is accepted into
> > > > > > kexec-tools.
> > > > >
> > > > > Sorry if I wasn't clear.
> > > > >
> > > > > I didn't mean that the feature should be merged into kexec-tools
> > > > > before merging the kernel bits. I just wanted to make sure there'=
s
> > > > > no fundamental issue from kexec-tools perspective.
> > > > >
> > > > > > Let me know how you would like to proceed.
> > > > >
> > > > > I'm going to wait for Baoquan's review and once that's done I'll
> > > > > pick up the kernel bits.
> > > >
> > > > Oh, sorry, I just noticed this series, but a quick look give me a
> > > > hint of 'No, I don't like it.' We have had Crash utility, Drgn, now
> > > > a new one comes up. I have some concerns to Pnina:
> > > >
> > > > 1. Exporting maple tree internals (maple_node, maple_range_64,
> > > >    maple_arange_64, maple_metadata) as vmcoreinfo ABI is problemati=
c.
> > > >    These are private implementation details, not stable structures =
like
> > > >    task_struct. Any refactoring of the maple tree will silently bre=
ak
> > > >    the userspace tool.
> > > >
> > > > 2. Without DWARF/BTF, the debugging scope is inherently limited =E2=
=80=94 no
> > > >    kernel stack backtrace, no symbol resolution, no variable access=
.
> > > >    That's essentially "ps + /proc/PID/maps" from a vmcore. Have you
> > > >    considered enabling CONFIG_DEBUG_INFO_BTF on your platforms inst=
ead?
> > > >    BTF is compact (typically < 1 MB) and would give drgn full acces=
s
> > > >    without needing vmlinux debug packages. That seems like a better
> > > >    return-on-investment than maintaining ~40 new vmcoreinfo exports=
.
> > > >
> > > > 3. Beyond the technical concerns, I wonder about adoption. vmcore-t=
asks
> > > >    targets a fairly narrow use case =E2=80=94 platforms without DWA=
RF/BTF, where
> > > >    you still have vmcore but can't ship vmlinux. Is Mobileye curren=
tly
> > > >    the only consumer? Are you guys already using it widely and full=
y?
> > > >    If this lands but doesn't see broader uptake, the ~40 exports ri=
sk
> > > >    becoming dead weight in vmcoreinfo =E2=80=94 nobody actively use=
s them, but
> > > >    kernel changes still need to keep them consistent, or they silen=
tly
> > > >    rot and give users wrong results.
> > > >
> > > > Regards,
> > > > Baoquan
> > >
> > > (Adding linux-debuggers mailing list).
> > >
> > > I agree with all of Baoquan's points here, with a couple of notes:
> > >
> > > 1. drgn's BTF support is currently a work in progress, but it's shapi=
ng
> > >    up well: https://github.com/osandov/drgn/pull/625.
> > > 2. makedumpfile is also gaining BTF extension support:
> > >    Suspicious Link - Removed
> > >    It's lighter-weight than drgn while still being much more general
> > >    than this series.
> >
> > Thanks for adding the information, very helpful.
>
> Hi,
>
> Thanks everyone for the feedback and the suggestions.
>
> I'll take a look at using BTF with vmcore-tasks and evaluate whether it c=
an replace most of the vmcoreinfo exports.
>
> Our use case requires analyzing the vmcore on the crash kernel itself, wi=
th very limited storage available, so using drgn together with a full vmlin=
ux is not practical for us.

I guess you can ship a makedumpfile and a few extensions to your
system, which shouldn't be too large. You can code a makedumpfile
extension to utilize BTF info(If your kernel already enabled it) to
iterate tasks and dump the needed information out, please see [1],
though it is used for ease some data from vmcore, but enough for print
any information.

[1]: https://github.com/makedumpfile/makedumpfile/blob/master/extensions/er=
ase_sample.c

Thanks,
Tao Liu
>
> Thanks,
> Pnina