Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S265614AbSKFGSv>; Wed, 6 Nov 2002 01:18:51 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S265615AbSKFGSv>; Wed, 6 Nov 2002 01:18:51 -0500
Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:17681 "EHLO
	neon-gw.transmeta.com") by vger.kernel.org with ESMTP
	id <S265614AbSKFGSt>; Wed, 6 Nov 2002 01:18:49 -0500
Date: Tue, 5 Nov 2002 22:25:35 -0800 (PST)
From: Linus Torvalds <torvalds@transmeta.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
       Werner Almesberger <wa@almesberger.net>,
       Suparna Bhattacharya <suparna@in.ibm.com>,
       Jeff Garzik <jgarzik@pobox.com>,
       "Matt D. Robinson" <yakker@aparity.com>,
       Rusty Russell <rusty@rustcorp.com.au>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       <lkcd-general@lists.sourceforge.net>,
       <lkcd-devel@lists.sourceforge.net>
Subject: Re: [lkcd-devel] Re: What's left over.
In-Reply-To: <m1d6pjfhhr.fsf@frodo.biederman.org>
Message-ID: <Pine.LNX.4.44.0211052203150.1416-100000@home.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2464
Lines: 83


On 5 Nov 2002, Eric W. Biederman wrote:
> 
> In replying to another post by Al Viro I managed to think this through.
> kexec needs:

Note that kexec doesn't bother me at all, and I might find myself using it 
myself.

>From a sanity standpoint, I think the thing already _has_ a system call, 
though: clearly "sys_reboot()" is the place to add a case for "reboot into 
this image". No? That's where we shut down devices anyway, and it's the 
sane place to say "reboot into the kexec image"

Which still leaves you with a real sys_kexec() to actually _load_ the
image, or course. I think loading of the image should be a totally
separate event from the actual booting of the image, since we may want to
load the image early, then do various user-level shutdown (unmounting 
etc), and then reboot.

Right now the kexec() stuff seems to mix up the loading and rebooting, but
I didn't take a very deep look, maybe I'm wrong.

Anyway, I don't really get why the kexec() system call would not just be

	void *kexec_image = NULL;
	unsigned long kexec_size;

	int sys_kexec(void *uaddr, size_t len)
	{
		void *new;

		if (!capable(CAP_ADMIN))
			return -EPERM;

		/* Get rid of old image if any.. */
		if (kexec_image) {
			vfree(kexec_image);
			kexec_image = NULL;
		}

		/* Zero length just meant "get rid of it" */
		if (!len)
			return 0;

		if (!access_ok(VERIFY_READ, uaddr, len))
			return -EFAULT;

		new = vmalloc(len);
		if (!new)
			return -ENOMEM;

		if (memcpy_from_user(new, uaddr, len)) {
			vfree(new);
			return -EFAULT;
		}

		kexec_image = new;
		kexec_size = len;
		return 0;
	}

and be done with it that way? Then the actual "reboot" (and that would be
in the existing "sys_reboot()") basically just does something like

	memcpy(kernelbase, kexec_image, kexec_size);

at the very end (while obviously having to be careful about itself being
out of the way. It can avoid the page table issue by using the "page *"
array that vmalloc uses internally anyway: see "area->pages[]" in
vmalloc).

Note that the two-phase boot means that you can load the new kernel early, 
which allows you to later on use it for oops handling (it's a bit late to 
try to set up the kernel to be loaded at that time ;)

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/