[PATCH] kexec: fix kexec_file_load fallback error handling

[Bradley Morgan]

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.

>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.

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

Thanks!