[PATCH] arm64/crashdump-arm64: Fix makedumpfile error caused by fail to get _text address

Pingfan Liu piliu at redhat.com
Sun Sep 21 21:38:34 PDT 2025


Hi Chen,

On Fri, Sep 19, 2025 at 3:35 PM Chen Wandun <chenwandun1 at gmail.com> 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 <zhaomeijing at lixiang.com>
> Signed-off-by: Chen Wandun <chenwandun at lixiang.com>
> ---
>  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
>




More information about the kexec mailing list