[PATCH] kexec: fix kexec_file_load fallback error handling

[Mukesh Pilaniya]

Hi Bradley, thanks for review.

On 22/08/26 12:44 am, Bradley Morgan wrote:
> On 14 August 2026 08:53:29 BST, Mukesh Pilaniya <mpilaniy at redhat.com>
> wrote:
>> With the default -a (--kexec-syscall-auto) option, kexec-tools first
>> tries kexec_file_load() and falls back to kexec_load() when the syscall
>> is not implemented (ENOSYS) or the kernel does not have a loader for the
>> image format (ENOEXEC/ENOTSUP). [...] Falling back on EINVAL hides the
>> real error, because EINVAL means something went wrong during loading.
>>
>> Remove EINVAL from the fallback path.
> 
> Hiding the real error behind a fallback is exactly what makes this one
> hurt to debug, so good direction.
> 
>> Several kexec_file_load() image probe functions incorrectly return
>> -EINVAL rather than -ENOEXEC when encountering an unrecognized image
>> format. This kernel patch fixes the issue:
>> https://lore.kernel.org/all/20260813-mpilaniy-v1-1-777d4d0e30f7@redhat.com/
> 
> That one is still being reworked, Pratyush just LGTM'd the
> probe_default change a couple days ago and the fix isn't in any tree
> yet. And until it is, the arm64 probe and the riscv image probe still
> return -EINVAL, and that last errno is what kexec_image_probe_default()
> leaks to userspace (I checked the loader lists in the tree). So if this
> lands on tools before the kernel fix lands, an image that used to
> silently fall back to kexec_load() on those arches now just fails with
> EINVAL.
> 
> Is the plan to hold this one until the kernel side is in? Because right
> now it looks like it can race ahead of its dependency.
> 
Yes, the kernel patch will merge first, then this one. I will follow up
on the same thread once the kernel fix is merged.

>> Print the actual errno for ENOEXEC/ENOTSUP before falling back
> 
> Good, that is the part that makes the s390 command line case visible.
> 
> The my_load/k_unload ENOSYS message hunks are unrelated cosmetics, fine
> but could be their own patch if you feel like splitting.
>
The my_load/k_unload ENOSYS hunks are not just cosmetic, they address a
misleading error output. Today, when kexec_load is absent, my_load dumps
the entry pointer, flags, and all segments, which is debug noise for
what is simply an unsupported syscall. Similar, k_unload prints "kexec
unload failed: Function not implemented", which reads like something
went wrong rather than the syscall not being available.

I'm happy to split this if you'd prefer, but since they're small and
directly related to the error-path cleanup, I kept them together.

> Its a good patch, I just want the ordering question answered first.
> 
> Thanks!

-- 
Regards,
Mukesh Pilaniya