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

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

[Pnina Feder]

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/

The series is structured as follows:

  Patch 1: Increase vmcoreinfo buffer from PAGE_SIZE to a fixed SZ_8K,
           decoupled from page size to avoid waste on large-page
           architectures (MIPS 16KB, arm64 64KB).

  Patch 2: Export generic struct offsets (task_struct, mm_struct,
           vm_area_struct, maple_tree, file/dentry/path, pt_regs,
           signal_struct) needed to walk task lists and VMAs.

  Patch 3: Export RISC-V arch-specific offsets (signal frame layouts,
           register context structures) for user register extraction.

  Patch 4: Export MIPS arch-specific offsets (signal frame layouts,
           register context structures) for user register extraction.

Additional architecture support (arm64, x86, etc.) can follow the
same pattern established by patches 3 and 4.

Tested on MIPS64 (QEMU Malta) and RISC-V with full kdump pipeline:
primary kernel -> kexec panic -> crash kernel -> vmcore-tasks analysis.

Pnina Feder (4):
  vmcoreinfo: increase vmcoreinfo buffer to 8KB
  vmcoreinfo: export task and mm struct offsets to vmcoreinfo
  riscv: vmcore_info: export riscv arch-specific struct offsets to
    vmcoreinfo
  mips: vmcore_info: export mips arch-specific struct offsets to
    vmcoreinfo

 .../admin-guide/kdump/vmcoreinfo.rst          | 137 ++++++++++++++++++
 arch/mips/kernel/Makefile                     |   1 +
 arch/mips/kernel/signal.c                     |   8 +
 arch/mips/kernel/vmcore_info.c                |  22 +++
 arch/riscv/kernel/signal.c                    |   8 +
 arch/riscv/kernel/vmcore_info.c               |  11 ++
 include/linux/vmcore_info.h                   |   3 +-
 kernel/vmcore_info.c                          |  60 ++++++++
 8 files changed, 249 insertions(+), 1 deletion(-)
 create mode 100644 arch/mips/kernel/vmcore_info.c

-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 1/4] vmcoreinfo: increase vmcoreinfo buffer to 8KB

[Pnina Feder]

Additional metadata will be exported to vmcoreinfo, requiring more
buffer space than a single 4KB page provides.

Change VMCOREINFO_BYTES from PAGE_SIZE to a fixed SZ_8K. This
decouples the buffer size from the page size, avoiding waste on
architectures with large pages (e.g. 16KB on MIPS, 64KB on arm64)
while providing enough space on 4KB-page architectures like RISC-V.

The existing allocation in kimage_crash_copy_vmcoreinfo() already
uses get_order() and DIV_ROUND_UP(), so it correctly rounds up to
whole pages regardless of the constant's value.

Signed-off-by: Pnina Feder <pnina.feder@mobileye.com>
---
 include/linux/vmcore_info.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/vmcore_info.h b/include/linux/vmcore_info.h
index e71518caacdf..612dcf7b9ecd 100644
--- a/include/linux/vmcore_info.h
+++ b/include/linux/vmcore_info.h
@@ -20,7 +20,8 @@
 				     CRASH_CORE_NOTE_NAME_BYTES +	\
 				     CRASH_CORE_NOTE_DESC_BYTES)
 
-#define VMCOREINFO_BYTES	   PAGE_SIZE
+/* Fixed size independent of PAGE_SIZE to avoid waste on large-page archs */
+#define VMCOREINFO_BYTES	   SZ_8K
 #define VMCOREINFO_NOTE_NAME	   "VMCOREINFO"
 #define VMCOREINFO_NOTE_NAME_BYTES ALIGN(sizeof(VMCOREINFO_NOTE_NAME), 4)
 #define VMCOREINFO_NOTE_SIZE	   ((CRASH_CORE_NOTE_HEAD_BYTES * 2) +	\
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 2/4] vmcoreinfo: export task and mm struct offsets to vmcoreinfo

[Pnina Feder]

Export the struct offsets and sizes needed by the vmcore-tasks tool
to walk task lists, extract register state, and enumerate VMAs from
a vmcore dump. This includes offsets into task_struct, mm_struct,
vm_area_struct, and related structures that are not already covered
by existing vmcoreinfo exports.

Signed-off-by: Pnina Feder <pnina.feder@mobileye.com>
---
 .../admin-guide/kdump/vmcoreinfo.rst          | 77 +++++++++++++++++++
 kernel/vmcore_info.c                          | 60 +++++++++++++++
 2 files changed, 137 insertions(+)

diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index 7663c610fe90..36103b3cdc05 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -594,3 +594,80 @@ va_kernel_pa_offset
 
 Indicates the offset between the kernel virtual and physical mappings.
 Used to translate virtual to physical addresses.
+
+Task and VMA metadata
+=====================
+
+The following vmcoreinfo entries export struct offsets and sizes needed
+to walk task lists, extract register state, and enumerate VMAs from a
+vmcore dump without requiring kernel debug symbols (DWARF/BTF). Used by
+the vmcore-tasks userspace tool for lightweight post-mortem crash
+analysis.
+
+init_task
+---------
+
+The address of the initial task (swapper). Used as the starting point
+to walk the circular task list via the tasks member.
+
+(task_struct, tasks)|(task_struct, pid)|(task_struct, tgid)|(task_struct, comm)|(task_struct, mm)|(task_struct, stack)|(task_struct, signal)|(task_struct, flags)|(task_struct, __state)|(task_struct, exit_state)|(task_struct, thread_node)
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+
+Offsets into task_struct needed to extract per-task metadata: process
+name, PID/TGID, task state, kernel stack pointer, mm_struct pointer,
+signal_struct pointer, and thread group linkage.
+
+(signal_struct, thread_head)|(signal_struct, nr_threads)
+--------------------------------------------------------
+
+Offsets into signal_struct for walking the thread group list and
+determining the number of threads.
+
+(mm_struct, mm_mt)|(mm_struct, pgd)|(mm_struct, start_brk)|(mm_struct, brk)|(mm_struct, start_stack)
+----------------------------------------------------------------------------------------------------
+
+Offsets into mm_struct for accessing the VMA maple tree, page global
+directory, and memory layout boundaries.
+
+Maple tree internals
+--------------------
+
+Offsets for maple_tree, maple_node, maple_range_64, maple_arange_64,
+and maple_metadata structures. These are needed to walk the maple tree
+that stores VMAs (mm_struct.mm_mt) from a vmcore dump.
+
+(vm_area_struct, vm_start)|(vm_area_struct, vm_end)|(vm_area_struct, vm_flags)|(vm_area_struct, vm_file)|(vm_area_struct, vm_mm)
+-------------------------------------------------------------------------------------------------------------------------------
+
+Offsets into vm_area_struct for extracting VMA boundaries, permissions,
+backing file, and owning mm_struct.
+
+(file, f_path)|(path, dentry)|(dentry, d_name)|(dentry, d_parent)|(qstr, hash_len)|(qstr, name)
+------------------------------------------------------------------------------------------------
+
+Offsets for traversing file -> path -> dentry -> name to reconstruct
+the filename backing a VMA.
+
+THREAD_SIZE
+-----------
+
+The size of the kernel stack. Used to locate the pt_regs saved at the
+top of the kernel stack for each task.
+
+(ucontext, uc_mcontext)
+-----------------------
+
+Offset of the machine context within struct ucontext. Used to locate
+saved registers within a signal frame.
+
+__NR_rt_sigreturn
+-----------------
+
+The rt_sigreturn syscall number. Used to identify signal frame return
+trampolines on the user stack during backtrace reconstruction.
+
+CONFIG_PGTABLE_LEVELS|PMD_SHIFT|PGDIR_SHIFT
+--------------------------------------------
+
+Page table geometry constants. Used for walking page tables to translate
+user virtual addresses to physical addresses in a vmcore dump.
diff --git a/kernel/vmcore_info.c b/kernel/vmcore_info.c
index 8614430ca212..f963274ab1a2 100644
--- a/kernel/vmcore_info.c
+++ b/kernel/vmcore_info.c
@@ -17,6 +17,7 @@
 
 #include <asm/page.h>
 #include <asm/sections.h>
+#include <asm/ucontext.h>
 
 #include "kallsyms_internal.h"
 #include "kexec_internal.h"
@@ -244,6 +245,65 @@ static int __init crash_save_vmcoreinfo_init(void)
 	VMCOREINFO_SYMBOL(kallsyms_offsets);
 #endif /* CONFIG_KALLSYMS */
 
+	VMCOREINFO_SYMBOL(init_task);
+	VMCOREINFO_STRUCT_SIZE(task_struct);
+	VMCOREINFO_OFFSET(task_struct, tasks);
+	VMCOREINFO_OFFSET(task_struct, thread_node);
+	VMCOREINFO_OFFSET(task_struct, pid);
+	VMCOREINFO_OFFSET(task_struct, tgid);
+	VMCOREINFO_OFFSET(task_struct, exit_state);
+	VMCOREINFO_OFFSET(task_struct, __state);
+	VMCOREINFO_OFFSET(task_struct, flags);
+	VMCOREINFO_OFFSET(task_struct, comm);
+	VMCOREINFO_OFFSET(task_struct, stack);
+	VMCOREINFO_OFFSET(task_struct, signal);
+	VMCOREINFO_OFFSET(signal_struct, thread_head);
+	VMCOREINFO_OFFSET(signal_struct, nr_threads);
+	VMCOREINFO_OFFSET(task_struct, mm);
+	VMCOREINFO_STRUCT_SIZE(mm_struct);
+	VMCOREINFO_OFFSET(mm_struct, mm_mt);
+	VMCOREINFO_OFFSET(mm_struct, pgd);
+	VMCOREINFO_OFFSET(mm_struct, start_brk);
+	VMCOREINFO_OFFSET(mm_struct, brk);
+	VMCOREINFO_OFFSET(mm_struct, start_stack);
+	VMCOREINFO_STRUCT_SIZE(maple_tree);
+	VMCOREINFO_OFFSET(maple_tree, ma_root);
+	VMCOREINFO_OFFSET(maple_tree, ma_flags);
+	VMCOREINFO_STRUCT_SIZE(maple_node);
+	VMCOREINFO_OFFSET(maple_node, slot);
+	VMCOREINFO_OFFSET(maple_node, parent);
+	VMCOREINFO_OFFSET(maple_node, ma64);
+	VMCOREINFO_OFFSET(maple_node, mr64);
+	VMCOREINFO_OFFSET(maple_range_64, pivot);
+	VMCOREINFO_OFFSET(maple_range_64, slot);
+	VMCOREINFO_OFFSET(maple_metadata, end);
+	VMCOREINFO_OFFSET(maple_metadata, gap);
+	VMCOREINFO_OFFSET(maple_arange_64, pivot);
+	VMCOREINFO_OFFSET(maple_arange_64, slot);
+	VMCOREINFO_OFFSET(maple_arange_64, gap);
+	VMCOREINFO_OFFSET(maple_arange_64, meta);
+	VMCOREINFO_STRUCT_SIZE(vm_area_struct);
+	VMCOREINFO_OFFSET(vm_area_struct, vm_start);
+	VMCOREINFO_OFFSET(vm_area_struct, vm_end);
+	VMCOREINFO_OFFSET(vm_area_struct, vm_flags);
+	VMCOREINFO_OFFSET(vm_area_struct, vm_file);
+	VMCOREINFO_OFFSET(vm_area_struct, vm_mm);
+	VMCOREINFO_STRUCT_SIZE(file);
+	VMCOREINFO_OFFSET(file, f_path);
+	VMCOREINFO_OFFSET(path, dentry);
+	VMCOREINFO_STRUCT_SIZE(dentry);
+	VMCOREINFO_OFFSET(dentry, d_name);
+	VMCOREINFO_OFFSET(dentry, d_parent);
+	VMCOREINFO_OFFSET(qstr, hash_len);
+	VMCOREINFO_OFFSET(qstr, name);
+	VMCOREINFO_NUMBER(THREAD_SIZE);
+	VMCOREINFO_STRUCT_SIZE(pt_regs);
+	VMCOREINFO_OFFSET(ucontext, uc_mcontext);
+	VMCOREINFO_NUMBER(__NR_rt_sigreturn);
+	VMCOREINFO_NUMBER(CONFIG_PGTABLE_LEVELS);
+	VMCOREINFO_NUMBER(PMD_SHIFT);
+	VMCOREINFO_NUMBER(PGDIR_SHIFT);
+
 	arch_crash_save_vmcoreinfo();
 	update_vmcoreinfo_note();
 
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 3/4] riscv: vmcore_info: export riscv arch-specific struct offsets to vmcoreinfo

[Pnina Feder]

Export RISC-V architecture-specific struct offsets needed by the
vmcore-tasks tool, including signal frame layouts and register
context structures used to reconstruct user-space register state
from a vmcore dump.

Signed-off-by: Pnina Feder <pnina.feder@mobileye.com>
---
 .../admin-guide/kdump/vmcoreinfo.rst          | 26 +++++++++++++++++++
 arch/riscv/kernel/signal.c                    |  8 ++++++
 arch/riscv/kernel/vmcore_info.c               | 11 ++++++++
 3 files changed, 45 insertions(+)

diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index 36103b3cdc05..3c364434b846 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -595,6 +595,32 @@ va_kernel_pa_offset
 Indicates the offset between the kernel virtual and physical mappings.
 Used to translate virtual to physical addresses.
 
+STACK_ALIGN
+-----------
+
+Stack alignment requirement for the architecture. Used to locate signal
+frames on the user stack.
+
+(sigcontext, sc_regs)
+---------------------
+
+Offset of the saved register array within struct sigcontext. Used to
+extract user-space register state from signal frames in a vmcore dump.
+
+_PAGE_PFN_SHIFT
+---------------
+
+The bit shift to extract the PFN from a page table entry. Used for
+virtual-to-physical address translation when walking page tables from
+a vmcore dump.
+
+(rt_sigframe, uc)
+-----------------
+
+Offset of the ucontext member within the RISC-V rt_sigframe structure.
+Used to locate the signal context (and thus saved registers) within a
+signal frame on the user stack.
+
 Task and VMA metadata
 =====================
 
diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
index 59784dc117e4..eb03c0ea6aae 100644
--- a/arch/riscv/kernel/signal.c
+++ b/arch/riscv/kernel/signal.c
@@ -13,6 +13,7 @@
 #include <linux/resume_user_mode.h>
 #include <linux/linkage.h>
 #include <linux/entry-common.h>
+#include <linux/vmcore_info.h>
 
 #include <asm/ucontext.h>
 #include <asm/vdso.h>
@@ -40,6 +41,13 @@ struct rt_sigframe {
 #endif
 };
 
+#ifdef CONFIG_VMCORE_INFO
+void riscv_rt_signal_frame(void)
+{
+	VMCOREINFO_OFFSET(rt_sigframe, uc);
+}
+#endif
+
 #ifdef CONFIG_FPU
 static long restore_fp_state(struct pt_regs *regs,
 			     union __riscv_fp_state __user *sc_fpregs)
diff --git a/arch/riscv/kernel/vmcore_info.c b/arch/riscv/kernel/vmcore_info.c
index c27efceec3cc..dd174042dba3 100644
--- a/arch/riscv/kernel/vmcore_info.c
+++ b/arch/riscv/kernel/vmcore_info.c
@@ -3,6 +3,12 @@
 #include <linux/vmcore_info.h>
 #include <linux/pagemap.h>
 
+#include <asm/processor.h>
+#include <asm/pgtable-bits.h>
+#include <asm/sigcontext.h>
+
+extern void riscv_rt_signal_frame(void);
+
 static inline u64 get_satp_value(void)
 {
 	return csr_read(CSR_SATP);
@@ -28,4 +34,9 @@ void arch_crash_save_vmcoreinfo(void)
 						kernel_map.va_kernel_pa_offset);
 	vmcoreinfo_append_str("KERNELOFFSET=%lx\n", kaslr_offset());
 	vmcoreinfo_append_str("NUMBER(satp)=0x%llx\n", get_satp_value());
+	riscv_rt_signal_frame();
+
+	VMCOREINFO_NUMBER(STACK_ALIGN);
+	VMCOREINFO_OFFSET(sigcontext, sc_regs);
+	VMCOREINFO_NUMBER(_PAGE_PFN_SHIFT);
 }
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 4/4] mips: vmcore_info: export mips arch-specific struct offsets to vmcoreinfo

[Pnina Feder]

Export MIPS architecture-specific struct offsets needed by the
vmcore-tasks tool, including signal frame layouts and register
context structures used to reconstruct user-space register state
from a vmcore dump.

Signed-off-by: Pnina Feder <pnina.feder@mobileye.com>
---
 .../admin-guide/kdump/vmcoreinfo.rst          | 34 +++++++++++++++++++
 arch/mips/kernel/Makefile                     |  1 +
 arch/mips/kernel/signal.c                     |  8 +++++
 arch/mips/kernel/vmcore_info.c                | 22 ++++++++++++
 4 files changed, 65 insertions(+)
 create mode 100644 arch/mips/kernel/vmcore_info.c

diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index 3c364434b846..4af32ddf5615 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -494,6 +494,40 @@ Used to get the vmalloc_start address from the high_memory symbol.
 
 The maximum number of CPUs.
 
+MIPS
+====
+
+(rt_sigframe, rs_uc)
+--------------------
+
+Offset of the ucontext member within the MIPS rt_sigframe structure.
+Used to locate the signal context within a signal frame on the user
+stack.
+
+(sigcontext, sc_regs)
+---------------------
+
+Offset of the saved register array within struct sigcontext. Used to
+extract user-space register state from signal frames in a vmcore dump.
+
+PAGE_SHIFT
+----------
+
+The base-2 logarithm of the page size. Used for page frame number
+calculations during address translation.
+
+_PFN_MASK|_PAGE_PRESENT|_PAGE_VALID|_PAGE_GLOBAL
+-------------------------------------------------
+
+Page table entry bit masks and flags. Used for walking MIPS page tables
+and translating virtual to physical addresses in a vmcore dump.
+
+PTRS_PER_PGD|PTRS_PER_PMD|PTRS_PER_PTE
+---------------------------------------
+
+Number of entries per page table level. Used for page table walking
+during virtual-to-physical address translation.
+
 powerpc
 =======
 
diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile
index 95a1e674fd67..99f2961f6ee1 100644
--- a/arch/mips/kernel/Makefile
+++ b/arch/mips/kernel/Makefile
@@ -24,6 +24,7 @@ CFLAGS_REMOVE_perf_event_mipsxx.o = $(CC_FLAGS_FTRACE)
 endif
 
 obj-$(CONFIG_CEVT_BCM1480)	+= cevt-bcm1480.o
+obj-$(CONFIG_VMCORE_INFO)	+= vmcore_info.o
 obj-$(CONFIG_CEVT_R4K)		+= cevt-r4k.o
 obj-$(CONFIG_CEVT_DS1287)	+= cevt-ds1287.o
 obj-$(CONFIG_CEVT_GT641XX)	+= cevt-gt641xx.o
diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c
index 4a10f18a8806..f2241f52fa17 100644
--- a/arch/mips/kernel/signal.c
+++ b/arch/mips/kernel/signal.c
@@ -26,6 +26,7 @@
 #include <linux/syscalls.h>
 #include <linux/uaccess.h>
 #include <linux/resume_user_mode.h>
+#include <linux/vmcore_info.h>
 
 #include <asm/abi.h>
 #include <asm/asm.h>
@@ -62,6 +63,13 @@ struct rt_sigframe {
 	struct ucontext rs_uc;
 };
 
+#ifdef CONFIG_VMCORE_INFO
+void mips_rt_signal_frame(void)
+{
+	VMCOREINFO_OFFSET(rt_sigframe, rs_uc);
+}
+#endif
+
 #ifdef CONFIG_MIPS_FP_SUPPORT
 
 /*
diff --git a/arch/mips/kernel/vmcore_info.c b/arch/mips/kernel/vmcore_info.c
new file mode 100644
index 000000000000..5d7fdc662065
--- /dev/null
+++ b/arch/mips/kernel/vmcore_info.c
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <linux/vmcore_info.h>
+
+#include <asm/pgtable.h>
+#include <asm/sigcontext.h>
+
+extern void mips_rt_signal_frame(void);
+
+void arch_crash_save_vmcoreinfo(void)
+{
+	mips_rt_signal_frame();
+	VMCOREINFO_OFFSET(sigcontext, sc_regs);
+	VMCOREINFO_NUMBER(PAGE_SHIFT);
+	VMCOREINFO_NUMBER(_PFN_MASK);
+	VMCOREINFO_NUMBER(_PAGE_PRESENT);
+	VMCOREINFO_NUMBER(_PAGE_VALID);
+	VMCOREINFO_NUMBER(_PAGE_GLOBAL);
+	VMCOREINFO_NUMBER(PTRS_PER_PGD);
+	VMCOREINFO_NUMBER(PTRS_PER_PMD);
+	VMCOREINFO_NUMBER(PTRS_PER_PTE);
+}
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Mike Rapoport]

(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@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.

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Simon Horman]

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

Let me know how you would like to proceed.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Mike Rapoport]

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.

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Baoquan He]

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






_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Simon Horman]

On Mon, Jul 20, 2026 at 03:43:11PM +0300, 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.

Thanks, it is clear :)

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

I see that conversation is now active.

Thanks to all.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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.


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv