Hi Chen, On Fri, Sep 19, 2025 at 3:35 PM Chen Wandun <[email protected]> wrote: > > I encountered the following error while makedumpfile without enableing > kernel CONFIG_PROC_KCORE and CONFIG_KALLSYMS_ALL, this error only exists > before commit 29fe506 (kexec: make -a the default), this commit change > from kexec_load to kexec_file_load. > > read_from_vmcore: Can't seek the dump memory(/proc/vmcore). (offset: > ffff800084f4c000) Invalid argument > readpage_elf: Can't read the dump memory(/proc/vmcore). > readmem: type_addr: 1, addr:41f29800, size:8 > vaddr_to_paddr_arm64: Can't read pgd > readmem: Can't convert a virtual address(ffff800082edf8a0) to physical > address. > readmem: type_addr: 0, addr:ffff800082edf8a0, size:390 > check_release: Can't get the address of system_utsname. > > Although several error messages appear when loading second kernel using kexec > without > kernel CONFIG_PROC_KCORE and CONFIG_KALLSYMS_ALL, but kexec return 0. > > Can't open (/proc/kcore). > Can't get the symbol of _text to calculate page_offset. > Can't get the symbol of _text to calculate page_offset. > > If kexec unable to get the _text address, it will result in > elf_info.kern_paddr_start > to be a large value, and also phdr->p_filesz/phdr->p_offset to be a large > value, such as: > > readelf -l /proc/vmcore > Program Headers: > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > NOTE 0x0000000000001000 0x0000000000000000 0x0000000000000000 > 0x0000000000001a44 0x0000000000001a44 0x4 > LOAD 0x0000000000003000 0xffffffffffffffff 0x00007fffc0200000 > 0xffff800083020000 0xffff800083020000 RWE 0x0 > LOAD 0xffff800083023000 0x0000000000000000 0x0000000040000000 > 0x00000001e6e00000 0x00000001e6e00000 RWE 0x0 > LOAD 0xffff800269e23000 0x00000001f6e00000 0x0000000236e00000 > 0x0000000009200000 0x0000000009200000 RWE 0x0 > > This patch avoiding makedumpfile failure by ending the kexec process and > explicitly > notifying error. >
I'm afraid I cannot agree with your proposed fix. The makedumpfile works on /proc/vmcore. In my opinion, if there isn't enough information for makedumpfile to work properly, you should try to fix and supplement it in the first kernel. Thanks, Pingfan > Reported-by: Zhao Meijing <[email protected]> > Signed-off-by: Chen Wandun <[email protected]> > --- > kexec/arch/arm64/crashdump-arm64.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/kexec/arch/arm64/crashdump-arm64.c > b/kexec/arch/arm64/crashdump-arm64.c > index 73cb611..8629610 100644 > --- a/kexec/arch/arm64/crashdump-arm64.c > +++ b/kexec/arch/arm64/crashdump-arm64.c > @@ -94,9 +94,11 @@ static int iomem_range_callback(void *UNUSED(data), int > UNUSED(nr), > * For compatibility, deduce by comparing the gap > "__init_begin - _stext" > * and the res size of "Kernel code" in /proc/iomem > */ > - if (kva_text_end - kva_stext == length) > + if (kva_text_end - kva_stext == length) { > + if (!kva_text) > + die("Cannot get kernel _text symbol > address\n"); > elf_info.kern_paddr_start = base - (kva_stext - > kva_text); > - else > + } else > elf_info.kern_paddr_start = base; > } > else if (strncmp(str, KERNEL_DATA, strlen(KERNEL_DATA)) == 0) > -- > 2.25.1 >
