Re: [PATCH v3 1/2] kexec: return -ENOEXEC from image probe functions on mismatch
Will Deacon <[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 | <ao2xc027TNYTwBA1@willie-the-truck> |
On Tue, Aug 25, 2026 at 10:43:48AM +0530, Mukesh Pilaniya wrote: > 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]. Fair enough, but I'd have thought it would be easier to special-case the one -ENOMEM path instead of changing all the backends to return -ENOEXEC all over the place (and hoping people don't start returning -EINVAL again in future). Will