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

[Baoquan He <baoquan.he@linux.dev>]

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 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@mobileye.com/
> > > 
> > > 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.
> 
> 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 problematic.
   These are private implementation details, not stable structures like
   task_struct. Any refactoring of the maple tree will silently break
   the userspace tool. 

2. Without DWARF/BTF, the debugging scope is inherently limited — 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 instead?
   BTF is compact (typically < 1 MB) and would give drgn full access
   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-tasks
   targets a fairly narrow use case — platforms without DWARF/BTF, where
   you still have vmcore but can't ship vmlinux. Is Mobileye currently
   the only consumer? Are you guys already using it widely and fully?
   If this lands but doesn't see broader uptake, the ~40 exports risk
   becoming dead weight in vmcoreinfo — nobody actively uses them, but
   kernel changes still need to keep them consistent, or they silently
   rot and give users wrong results. 

Regards,
Baoquan