Re: [PATCH] LoongArch: kdump: add arch_crash_save_vmcoreinfo() support

[sashiko-bot@kernel.org]

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