Re: [PATCH v3 1/2] kexec: return -ENOEXEC from image probe functions on mismatch
Mukesh Pilaniya <[email protected]>
| Newsgroups | dev.linux.lists.loongarch,org.infradead.lists.kexec,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-riscv,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
Hi Will, On 24/08/26 7:37 pm, Will Deacon wrote: > On Fri, Aug 21, 2026 at 07:19:57PM +0530, Mukesh Pilaniya wrote: >> Several kexec_file_load() image probe functions return -EINVAL when >> they do not recognize the image format. A probe function that rejects >> an image should return -ENOEXEC to indicate that the image is not a >> recognized executable format. -EINVAL implies a problem with the >> syscall parameters, not with image recognition. >> >> kexec_image_probe_default() iterates through registered loaders and >> returns the last probe's error code to the caller. That error >> propagates as the kexec_file_load() return value to userspace. >> Returning -EINVAL from a probe when no loader matches is semantically >> incorrect and misleads userspace about the nature of the failure. >> >> Return -ENOEXEC from all probe functions and their helpers when the >> image format is not recognized. >> >> Signed-off-by: Mukesh Pilaniya <[email protected]> >> Reviewed-by: Philipp Rudo <[email protected]> >> Reviewed-by: Pratyush Yadav <[email protected]> >> Reviewed-by: Bradley Morgan <[email protected]> >> --- >> arch/arm64/kernel/kexec_image.c | 4 ++-- >> arch/loongarch/kernel/kexec_efi.c | 4 ++-- >> arch/riscv/kernel/kexec_image.c | 4 ++-- >> kernel/kexec_elf.c | 4 ++-- >> 4 files changed, 8 insertions(+), 8 deletions(-) > > Hmm, so after this patch, are there actually any implementations of .probe() > that return anything other than 0 or -ENOEXEC? I couldn't spot any after > a quick look. > > Willkexec_elf_probe() can return -ENOMEM if memory allocation (kzalloc()) fails inside elf_read_phdrs(). This behavior was previously discussed in the first patch of this series [1]. [1] https://lore.kernel.org/all/[email protected]/#t -- Regards, Mukesh Pilaniya