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

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

[Omar Sandoval]

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 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

(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 shaping
   up well: https://github.com/osandov/drgn/pull/625.
2. makedumpfile is also gaining BTF extension support:
   https://lore.kernel.org/all/20260617051834.95404-1-ltao@redhat.com/.
   It's lighter-weight than drgn while still being much more general
   than this series.

Thanks,
Omar

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

[Baoquan He]

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 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
> 
> (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 shaping
>    up well: https://github.com/osandov/drgn/pull/625.
> 2. makedumpfile is also gaining BTF extension support:
>    https://lore.kernel.org/all/20260617051834.95404-1-ltao@redhat.com/.
>    It's lighter-weight than drgn while still being much more general
>    than this series.

Thanks for adding the information, very helpful.

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

[Pnina Feder]

> 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 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:
> > > > > > >   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 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
> > 
> > (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 shaping
> >    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 can replace most of the vmcoreinfo exports.

Our use case requires analyzing the vmcore on the crash kernel itself, with very limited storage available, so using drgn together with a full vmlinux is not practical for us.

Thanks,
Pnina

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

[Tao Liu]

On Fri, Jul 24, 2026 at 1:05 AM Pnina Feder <PNINA.FEDER@mobileye.com> 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 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:
> > > > > > > >   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 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
> > >
> > > (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 shaping
> > >    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 can replace most of the vmcoreinfo exports.
>
> Our use case requires analyzing the vmcore on the crash kernel itself, with very limited storage available, so using drgn together with a full vmlinux 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/erase_sample.c

Thanks,
Tao Liu
>
> Thanks,
> Pnina