[PATCH v5 4/5] kexec: Add option to fall back to KEXEC_LOAD when KEXEC_FILE_LOAD is not supported
msuchanek at suse.de
Mon Mar 26 12:07:46 PDT 2018
On Mon, 26 Mar 2018 15:52:39 -0300
Thiago Jung Bauermann <bauerman at linux.vnet.ibm.com> wrote:
> Michal Suchánek <msuchanek at suse.de> writes:
> > On Mon, 26 Mar 2018 17:12:10 +0800
> > Dave Young <dyoung at redhat.com> wrote:
> >> On 03/26/18 at 05:08pm, Dave Young wrote:
> >> > On 03/20/18 at 04:56pm, Michal Suchanek wrote:
> >> > Hmm, this is still used in latest version. kernel does not
> >> > return such error number, I might not say clearly previously.
> >> > Please check the kernel code, the only one place I know is
> >> > because no kdump support in power kexec_file:
> >> > arch/powerpc/kernel/machine_kexec_file_64.c
> >> >
> >> > /* We don't support crash kernels yet. */
> >> > if (image->type == KEXEC_TYPE_CRASH)
> >> > return -ENOTSUPP;
> >> >
> >> > So I suggest not checking this as well since -ENOTSUPP is not
> >> > populated in userspace headers, and -ENOTSUP is not used at all.
> >> >
> >> > For -ENOTSUP, maybe someone can submit a patch to switch to
> >> > -ENOTSUPP so that userspace can check it.
> >> > Ccing Thiago and Hari for the -ENOTSUPP errno issue.
> >> Oops for the hurry reply, I means -ENOTSUPP might be able to
> >> replaced with -EOPNOTSUPP, a similar change like this:
> >> https://patchwork.kernel.org/patch/8490791/
> > Thanks for catching this. In Linux ENOTSUPP with extra P is
> > different from EOPNOTSUPP and ENOTSUP (single P). Since we are
> > talking to the kernel and it returns the double P ENOTSUPP we need
> > to define it in kexec as well. And we should check ENOTSUP with
> > single P in case somebody some day thinks that returning undefined
> > error codes to userspace is not nice like in the patch above.
> I wasn't aware that ENOTSUPP was an in-kernel only errno. Should I
> submit a patch for the kernel so that powerpc returns -EOPNOTSUPP in
> case of trying to load kdump kernel with kexec_file_load()?
It does not help us much because we need to support kernels without the
patch as well. In the long run it might be nice to eliminate the return
value in user-facing functions. But it's difficult to tell which
functions are user-facing. The return value can be forwarded quite a
few times before it reaches the user.
This is far from the only place returning this error code to userspace.
I wonder what was the reason for introducing this error code in the
More information about the kexec