Re: [linux-next-20250212] syscall kexec_file_load not available

[Sourabh Jain]

On 14/02/25 12:38, Hari Bathini wrote:
> On 14/02/25 12:15 pm, Sourabh Jain wrote:
> > Hello Hari,
> >
> >
> > On 14/02/25 12:02, Hari Bathini wrote:
> > > On 13/02/25 8:34 pm, Venkat Rao Bagalkote wrote:
> > > > Greetings!!!
> > > >
> > > >  From kernel next-20250210, I am observing syscall kexec_file_load 
> > > > not available, there by kdump service is failing to start.
> > > >
> > > >
> > > > Logs:
> > > >
> > > > [root@ltc-zzci-1 ~]# kexec -p --initrd=/boot/initramfs-6.14.0-rc2- 
> > > > next-20250212kdump.img /boot/vmlinuz-6.14.0-rc2-next-20250212 -c
> > > > Warning: append= option is not passed. Using the first kernel root 
> > > > partition
> > > > Modified cmdline: elfcorehdr=311424K root=UUID=b5b1f89c- 
> > > > d479-48b3-90e2-744a2fd05667
> > > > [root@ltc-zzci-1 ~]# kexec -p --initrd=/boot/initramfs-6.14.0-rc2- 
> > > > next-20250212kdump.img /boot/vmlinuz-6.14.0-rc2-next-20250212 -s
> > > > syscall kexec_file_load not available.
> > > > [root@ltc-zzci-1 ~]# kexec -v
> > > > kexec-tools 2.0.27
> > > > [root@ltc-zzci-1 ~]# uname -r
> > > > 6.14.0-rc2-next-20250212
> > >
> > > Is the kernel built with CONFIG_KEXEC_FILE ?
> >
> > I am able to reproduce it with CONFIG_KEXEC_FILE enabled.
> >
> > Seems like there is something went wrong in next-20250210 and 
> > next-20250212.
> >
> > kexec -p --initrd=/boot/initramfs-6.14.0-rc2-next-20250210kdump.img / 
> > boot/vmlinuz-6.14.0-rc2-next-20250210 -d -s
> >
> > Try gzip decompression.
> > Try LZMA decompression.
> > [ 3375.712319] kexec_file: kernel: 00000000e539303c kernel_size: 
> > 0x2cdacf0
> > [ 3375.717022] ima: kexec measurement buffer for the loaded kernel at 
> > 0x0.
> > [ 3375.717076] kexec_elf: Loaded the kernel at 0x0
> > [ 3375.717094] kexec_elf: Loaded purgatory at 0x0
> > [ 3375.717104] Loaded the backup region at 0x0
> > [ 3375.717130] crash_core: Crash PT_LOAD ELF header. 
> > phdr=000000004720e656 vaddr=0xc000000000000000, paddr=0x0, sz=0x10000 
> > e_phnum=18 p_offset=0x0
> > [ 3375.717156] crash_core: Crash PT_LOAD ELF header. 
> > phdr=0000000005eb3f14 vaddr=0xc000000000010000, paddr=0x10000, 
> > sz=0xfff0000 e_phnum=19 p_offset=0x10000
> > [ 3375.717174] crash_core: Crash PT_LOAD ELF header. 
> > phdr=000000000ec70071 vaddr=0xc00000001ec20000, paddr=0x1ec20000, 
> > sz=0x13e0000 e_phnum=20 p_offset=0x1ec20000
> > [ 3375.717192] crash_core: Crash PT_LOAD ELF header. 
> > phdr=00000000b66c9c25 vaddr=0xc000000050000000, paddr=0x50000000, 
> > sz=0x3b0000000 e_phnum=21 p_offset=0x50000000
> > [ 3375.717215] Loaded elf core header at 0x0, bufsz=0x1000 memsz=0x80000
> > [ 3375.717229] kexec_elf: Loaded initrd at 0x0
> > [ 3375.718043] Memory node path: /memory@0
> > [ 3375.722854] kexec_elf: Loaded device tree at 0x0
> > syscall kexec_file_load not available.
> >
> > Kernel is reporting that all kexec segments are getting loaded at 0x0.
> >
> > Running kexec with strace shows that kexec_file_load system return -1 
> > EINVAL.
> >
> > kexec_file_load(3, 4, 1, "\0", KEXEC_FILE_ON_CRASH) = -1 EINVAL 
> > (Invalid argument)
> >
> > Based on the logs printed on the console and kexec_file_load return 
> > value. I am suspecting
> > kexec_file_load returned early form sanity_check_segment_list() 
> > because the segment is 0x0.
> >
> > I am investigating further to find how segment.mem for all segment is 
> > 0x0.
>
> Interesting. Thanks for the update, Sourabh.
> I believe the error "syscall kexec_file_load not available." is
> inappropriate and misleading. That should be fixed too.

Agree. It is happening because kexec is handling ENOSYS, EINVAL, 
ENOEXEC, and ENOTSUP
as a single case and printing "syscall kexec_file_load not available".

I will send a fix for kexec tool to avoid this confusing error message.

Thanks,
Sourabh Jain