[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1od6w4jxx.fsf@frodo.ebiederm.org>
Date: Fri, 23 May 2008 17:36:26 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Bernhard Walle <bwalle@...e.de>
Cc: Sharyathi Nagesh <sharyath@...ibm.com>, akpm@...l.org,
mohd.omar@...ibm.com, IndhuDurai@...ibm.com,
Kexec Mailing List <kexec@...ts.infradead.org>,
fastboot@...ts.osdl.org, linux-kernel@...r.kernel.org,
mohan@...ibm.com, sachinp@...ibm.com
Subject: Re: correction to compat_sys_kexec_load
Bernhard Walle <bwalle@...e.de> writes:
> * ebiederm@...ssion.com (Eric W. Biederman) [2008-05-23 13:14]:
>>
>> 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.
>
> How should it know that it unloads a 32 bit kernel on a 64 bit system?
> It doesn't have access to the kernel any more once it has been loaded.
The architecture parameter is the architecture of the running kernel
that implements sys_kexec_load.
Because it is a pain for testing and in general impossible we don't
change cpu modes during a kexec. So a 32bit caller of sys_kexec_load
will need to passing in different code if it is running on a 32bit or
a 64bit kernel.
The trampoline code in /sbin/kexec does change modes on x86 when
appropriate.
Caring if you know the architecture in the unload case is a bit
silly. As there is no real justification for it. At this
point getting user space fixed so that it works on older kernels
seems important.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists