On 9/22/25 12:38 PM, Pingfan Liu wrote:
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.
Yes, you're right, and that's also how this patch is done;
Without this patch:
If kexec can't get the address of _text, kexec will finish “normally”
with returning 0,
but will fail when makedumpfile. This is not what we expected.
With this patch:
kexec will abort if can't get the address ot _text and explicitly
notifying error, and
first kernel should provide correct info based on error message.
Thanks,
Wandun
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
