public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Sharyathi Nagesh <sharyath@in.ibm.com>
Cc: linux-kernel@vger.kernel.org, fastboot@lists.osdl.org,
	akpm@osdl.org, maneesh@in.ltcfwd.linux.ibm.com, mohan@in.ibm.com,
	sachinp@in.ibm.com, mohd.omar@in.ibm.com, IndhuDurai@in.ibm.com,
	Kexec Mailing List <kexec@lists.infradead.org>
Subject: Re: correction to compat_sys_kexec_load
Date: Fri, 23 May 2008 13:14:42 -0700	[thread overview]
Message-ID: <m1ve144w25.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <4836AC3C.3090005@in.ibm.com> (Sharyathi Nagesh's message of "Fri, 23 May 2008 17:06:28 +0530")

Sharyathi Nagesh <sharyath@in.ibm.com> writes:

> Hi
>   While testing with kexec tool, I observed some problems. When application
> (kexec) is 32 bit and kernel is 64 bit I observed that loading crash kernel
> works without any issues but unloading crash kernel fails.
> --------------------------------------------------------
> running strace over 'kexec -u -p'
> show the problem to be with sys_kexec_load() call
>
> sys_kexec_load(0, 0, 0, 0x1, 0)         = -1 EINVAL (Invalid argument)
> write(2, "kexec_load (0 segments) failed: "..., 49
> kexec_load (0 segments) failed: Invalid argument
> ) = 4

Yes.  This is a bug.  Although not in the kernel implementation.

> --------------------------------------------------------
>
> This is patch to fix the problem, I think kernel code had a typo where in:
> if((flags & KEXEC_ARCH_MASK) == KEXEC_ARCH) was used instead of
> if((flags & KEXEC_ARCH_MASK) != KEXEC_ARCH)

Nope.  We do the latter check after we have fixed up the arguments
and call sys_kexec_load.  The check really is meant to filter out
KEXEC_ARCH_DEFAULT.


> This patch takes care of that, I have tested the patch it worked fine for
> me. Please review the patch and let me know of your views. This patch is based
> on linux-2.6.26-rc3.

That patch as it exists is actively bad.  It removes the check for a really
nasty gotcha if someone passes in KEXEC_ARCH_DEFAULT in 32bit mode.  Code
expecting a 32bit handoff and getting a 64bit handoff will explode in fun
ways.  You happened to test the one corner case where this does not matter.

What we need to do is fix /sbin/kexec to pass in the correct
architecture of the kernel for unload as it does for load.

Eric

  reply	other threads:[~2008-05-23 20:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-23 11:36 correction to compat_sys_kexec_load Sharyathi Nagesh
2008-05-23 20:14 ` Eric W. Biederman [this message]
2008-05-23 21:33   ` Bernhard Walle
2008-05-24  0:36     ` Eric W. Biederman
2008-05-26 20:32       ` Bernhard Walle
2008-05-28  4:39         ` Sharyathi Nagesh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1ve144w25.fsf@frodo.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=IndhuDurai@in.ibm.com \
    --cc=akpm@osdl.org \
    --cc=fastboot@lists.osdl.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maneesh@in.ltcfwd.linux.ibm.com \
    --cc=mohan@in.ibm.com \
    --cc=mohd.omar@in.ibm.com \
    --cc=sachinp@in.ibm.com \
    --cc=sharyath@in.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox