* [PATCH] LoongArch: kdump: add arch_crash_save_vmcoreinfo() support
@ 2026-09-23 6:03 Yangyang Lian
2026-09-23 6:16 ` sashiko-bot
0 siblings, 1 reply; 2+ messages in thread
From: Yangyang Lian @ 2026-09-23 6:03 UTC (permalink / raw)
To: Andrew Morton, Baoquan He, Mike Rapoport, Pasha Tatashin,
Pratyush Yadav, Huacai Chen
Cc: Dave Young, WANG Xuerui, kexec, loongarch, linux-kernel,
Yangyang Lian, Haoran Jiang, George Guo
Since commit 23c85094fe18 ("proc/kcore: add vmcoreinfo note to
/proc/kcore") the kernel has exported the vmcoreinfo PT_NOTE on
/proc/kcore as wellas /proc/vmcore.
LoongArch does not provide arch_crash_save_vmcoreinfo(), so the
arch-specific values are missing from the vmcoreinfo PT_NOTE. The
generic exporter in kernel/vmcore_info.c already provides
NUMBER(VMALLOC_START), but tools like crash cannot derive the module
and vmemmap ranges, VA_BITS, or the KASLR offset of a LoongArch dump.
Since commit 18210a104bb9 ("LoongArch: Expand module virtual address
space to 2GB") the vmalloc and module boundaries are no longer stable
across kernel versions either, so vmcoreinfo is the only reliable
source for them.
Provide this function in a separate file that is built at the same time
as its caller in kernel/vmcore_info.c, and add a LOONGARCH64 section to
Documentation/admin-guide/kdump/vmcoreinfo.rst.
Reported-by: Haoran Jiang <jianghaoran@kylinos.cn>
Suggested-by: Haoran Jiang <jianghaoran@kylinos.cn>
Co-developed-by: George Guo <guodongtai@kylinos.cn>
Signed-off-by: George Guo <guodongtai@kylinos.cn>
Signed-off-by: Yangyang Lian <lianyangyang@kylinos.cn>
---
.../admin-guide/kdump/vmcoreinfo.rst | 29 +++++++++++++++++++
arch/loongarch/kernel/Makefile | 1 +
arch/loongarch/kernel/vmcore_info.c | 21 ++++++++++++++
3 files changed, 51 insertions(+)
create mode 100644 arch/loongarch/kernel/vmcore_info.c
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index 7663c610fe90..2ff921232616 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -594,3 +594,32 @@ va_kernel_pa_offset
Indicates the offset between the kernel virtual and physical mappings.
Used to translate virtual to physical addresses.
+
+LOONGARCH64
+===========
+
+VA_BITS
+-------
+
+The maximum number of bits for virtual addresses. Used to compute the
+virtual memory ranges.
+
+PHYS_OFFSET
+-----------
+
+Indicates the physical address of the start of memory. Used to translate
+virtual to physical addresses.
+
+KERNELOFFSET
+------------
+
+The kernel randomization offset. Used to locate the kernel text in
+virtual memory. If KASLR is disabled, this value is zero.
+
+MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END
+-----------------------------------------------------------------------------
+
+Used to get the correct ranges:
+ MODULES_VADDR ~ MODULES_END-1 : Kernel module space.
+ VMALLOC_START ~ VMALLOC_END-1 : vmalloc() / ioremap() space.
+ VMEMMAP_START ~ VMEMMAP_END-1 : vmemmap region, used for struct page array.
diff --git a/arch/loongarch/kernel/Makefile b/arch/loongarch/kernel/Makefile
index 001924877772..6260c15adaba 100644
--- a/arch/loongarch/kernel/Makefile
+++ b/arch/loongarch/kernel/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_RELOCATABLE) += relocate.o
obj-$(CONFIG_KEXEC_CORE) += machine_kexec.o relocate_kernel.o
obj-$(CONFIG_KEXEC_FILE) += machine_kexec_file.o kexec_efi.o kexec_elf.o
obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
+obj-$(CONFIG_VMCORE_INFO) += vmcore_info.o
obj-$(CONFIG_UNWINDER_GUESS) += unwind_guess.o
obj-$(CONFIG_UNWINDER_PROLOGUE) += unwind_prologue.o
diff --git a/arch/loongarch/kernel/vmcore_info.c b/arch/loongarch/kernel/vmcore_info.c
new file mode 100644
index 000000000000..1128f6cdfe0d
--- /dev/null
+++ b/arch/loongarch/kernel/vmcore_info.c
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/vmcore_info.h>
+#include <asm/addrspace.h>
+#include <asm/pgtable.h>
+#include <asm/setup.h>
+
+void arch_crash_save_vmcoreinfo(void)
+{
+ VMCOREINFO_NUMBER(VA_BITS);
+ /* NUMBER(VMALLOC_START) is exported by the generic code */
+ vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
+#ifdef CONFIG_64BIT
+ vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
+ vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
+ vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", (unsigned long)vmemmap);
+ vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
+#endif
+ vmcoreinfo_append_str("NUMBER(PHYS_OFFSET)=0x%lx\n", PHYS_OFFSET);
+ vmcoreinfo_append_str("KERNELOFFSET=%lx\n", kaslr_offset());
+}
--
2.25.1
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] LoongArch: kdump: add arch_crash_save_vmcoreinfo() support
2026-09-23 6:03 [PATCH] LoongArch: kdump: add arch_crash_save_vmcoreinfo() support Yangyang Lian
@ 2026-09-23 6:16 ` sashiko-bot
0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-09-23 6:16 UTC (permalink / raw)
To: Mike Rapoport, Pratyush Yadav, Huacai Chen, Pasha Tatashin,
Yangyang Lian, Andrew Morton, Baoquan He
Cc: Haoran Jiang, loongarch, WANG Xuerui, George Guo, Dave Young,
kexec, linux-kernel
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] kdump: off-by-one in VMEMMAP_END export causes incorrect range in tools
--
commit 39488158a1b2af61bc47f6be1cf24b8ef1c6d7cd
Author: Yangyang Lian <lianyangyang@kylinos.cn>
LoongArch: kdump: add arch_crash_save_vmcoreinfo() support
This commit implements arch_crash_save_vmcoreinfo() for LoongArch to export
architecture-specific values to the vmcoreinfo PT_NOTE. This allows userspace
crash analysis tools to reliably derive module ranges, vmemmap ranges, VA_BITS,
and the KASLR offset.
> diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst
> index 404a15f6782c3..a714ce4cf2141 100644
> --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
> +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
[ ... ]
> +MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END
> +-----------------------------------------------------------------------------
> +
> +Used to get the correct ranges:
> + MODULES_VADDR ~ MODULES_END-1 : Kernel module space.
> + VMALLOC_START ~ VMALLOC_END-1 : vmalloc() / ioremap() space.
> + VMEMMAP_START ~ VMEMMAP_END-1 : vmemmap region, used for struct page array.
[ ... ]
> diff --git a/arch/loongarch/kernel/vmcore_info.c b/arch/loongarch/kernel/vmcore_info.c
> new file mode 100644
> index 0000000000000..1128f6cdfe0dd
> --- /dev/null
> +++ b/arch/loongarch/kernel/vmcore_info.c
[ ... ]
> +void arch_crash_save_vmcoreinfo(void)
> +{
> + VMCOREINFO_NUMBER(VA_BITS);
> + /* NUMBER(VMALLOC_START) is exported by the generic code */
> + vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> +#ifdef CONFIG_64BIT
> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> + vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", (unsigned long)vmemmap);
> + vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
[Severity: Medium]
Is this exporting the correct boundary for VMEMMAP_END?
As documented in the newly added admin-guide for vmcoreinfo (above), tools
like crash or makedumpfile expect the exported VMEMMAP_END to act as an
exclusive bound (VMEMMAP_START ~ VMEMMAP_END-1).
However, on LoongArch, the VMEMMAP_END macro is defined as an inclusive bound.
Exporting it directly without adjusting it to an exclusive bound
(e.g., VMEMMAP_END + 1) means the exported value is off by one byte.
Could this cause tools calculating the size via VMEMMAP_END - VMEMMAP_START
to get VMEMMAP_SIZE - 1, thereby truncating the last page when shifted and
triggering errors when analyzing the vmcore?
> +#endif
> + vmcoreinfo_append_str("NUMBER(PHYS_OFFSET)=0x%lx\n", PHYS_OFFSET);
> + vmcoreinfo_append_str("KERNELOFFSET=%lx\n", kaslr_offset());
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260923060349.146780-1-lianyangyang@kylinos.cn?part=1
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-09-23 6:16 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-23 6:03 [PATCH] LoongArch: kdump: add arch_crash_save_vmcoreinfo() support Yangyang Lian
2026-09-23 6:16 ` sashiko-bot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®