[linux-next-20250212] syscall kexec_file_load not available

[linux-next-20250212] syscall kexec_file_load not available

[Venkat Rao Bagalkote]

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


Regards,

Venkat.

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

[Sourabh Jain]

Hello Venkat,


On 13/02/25 20:34, 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.
>

powerpc do have support for kexec_file_load system. Seems like there is 
an issue.

Thanks for reporting the issue.

I will debug and find what went wrong with next-20250210 or the kexec 
you used to load the kdump kernel.

Thanks,
Sourabh Jain

>
> 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
>
>
> Regards,
>
> Venkat.
>

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

[Hari Bathini]

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 ?

- Hari

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

[Venkat Rao Bagalkote]

Yes Hari, its built with CONFIG_KEXEC_FILE=y

Regards,

Venkat.

On 14/02/25 12:02 pm, 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 ?
>
> - Hari
>

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

[Sourabh Jain]

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.

Thanks,
Sourabh Jain

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

[Hari Bathini]

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.

- Hari

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

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

[Sourabh Jain]

Hello,


On 14/02/25 12:15, 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.


Posted a fix upstream:
https://lore.kernel.org/all/20250214125402.90709-1-sourabhjain@linux.ibm.com/


Thanks,
Soiurabh Jain