I observed the problem that even when you choose the default 16M as
crashkernel base address and the kernel is very big, the reserved area may
overlap with the kernel BSS. Currently, this is not checked at runtime, so the
kernel just crashes when you load the panic kernel in the sys_kexec call.
This two patches check this at runtime. The patches are against current git,
but with the patches
extended-crashkernel-command-line.patch
extended-crashkernel-command-line-update.patch
extended-crashkernel-command-line-comment-fix.patch
extended-crashkernel-command-line-improve-error-handling-in-parse_crashkernel_mem.patch
use-extended-crashkernel-command-line-on-i386.patch
use-extended-crashkernel-command-line-on-i386-update.patch
use-extended-crashkernel-command-line-on-x86_64.patch
use-extended-crashkernel-command-line-on-x86_64-update.patch
use-extended-crashkernel-command-line-on-ia64.patch
use-extended-crashkernel-command-line-on-ia64-fix.patch
use-extended-crashkernel-command-line-on-ia64-update.patch
use-extended-crashkernel-command-line-on-ppc64.patch
use-extended-crashkernel-command-line-on-ppc64-update.patch
use-extended-crashkernel-command-line-on-sh.patch
use-extended-crashkernel-command-line-on-sh-update.patch
from -mm tree applied since they are marked to be merged in 2.6.24.
I know that the implementation of both patches is only x86 (i386 and x86-64),
but if you agree that it's the way to go, I can add the BSS resource
and the check for all other architectures that apply.
Signed-off-by: Bernhard Walle <[email protected]>
--
On Mon, Oct 15, 2007 at 01:50:42PM +0200, Bernhard Walle wrote:
> I observed the problem that even when you choose the default 16M as
> crashkernel base address and the kernel is very big, the reserved area may
> overlap with the kernel BSS. Currently, this is not checked at runtime, so the
> kernel just crashes when you load the panic kernel in the sys_kexec call.
>
> This two patches check this at runtime. The patches are against current git,
> but with the patches
>
> extended-crashkernel-command-line.patch
> extended-crashkernel-command-line-update.patch
> extended-crashkernel-command-line-comment-fix.patch
> extended-crashkernel-command-line-improve-error-handling-in-parse_crashkernel_mem.patch
> use-extended-crashkernel-command-line-on-i386.patch
> use-extended-crashkernel-command-line-on-i386-update.patch
> use-extended-crashkernel-command-line-on-x86_64.patch
> use-extended-crashkernel-command-line-on-x86_64-update.patch
> use-extended-crashkernel-command-line-on-ia64.patch
> use-extended-crashkernel-command-line-on-ia64-fix.patch
> use-extended-crashkernel-command-line-on-ia64-update.patch
> use-extended-crashkernel-command-line-on-ppc64.patch
> use-extended-crashkernel-command-line-on-ppc64-update.patch
> use-extended-crashkernel-command-line-on-sh.patch
> use-extended-crashkernel-command-line-on-sh-update.patch
>
> from -mm tree applied since they are marked to be merged in 2.6.24.
>
> I know that the implementation of both patches is only x86 (i386 and x86-64),
> but if you agree that it's the way to go, I can add the BSS resource
> and the check for all other architectures that apply.
>
Hi Bernhard,
Shouldn't bootmem allocator have the functionality to flag an error if
we try to reserve a memory which is already reserved? I see that bootmem
allocator is currently printing a warning under CONFIG_DEBUG_BOOTMEM.
Wouldn't it be better if we reserve the code, data and bss memory also
using bootmem allocator and when somebody tries to reserve craskernel memory
and if there is an overlap, boot memory allocator should scream?
In second patch, you are checking for crash kernel reserved memory being
beyond _end. That will make sure that there is no overlap with kernel
text, data or bss. I am wondering then why do we need first patch and
why should we register bss memory in the resources list. Second patch
would make sure that there is no overlap with crash kernel memory and kexec
will not place any segment outside crashkernel memory.
Thanks
Vivek
Vivek Goyal <[email protected]> writes:
> Wouldn't it be better if we reserve the code, data and bss memory also
> using bootmem allocator and when somebody tries to reserve craskernel memory
> and if there is an overlap, boot memory allocator should scream?
Some x86 bootmem code right now relies on it not screaming (or at least not
erroring out). That would need to be fixed first. Or you make it a flag.
Would probably make sense, except that we already have too many bootmem
allocation variants :/
-Andi
* Andi Kleen <[email protected]> [2007-10-16 11:59]:
> Vivek Goyal <[email protected]> writes:
>
> > Wouldn't it be better if we reserve the code, data and bss memory also
> > using bootmem allocator and when somebody tries to reserve craskernel memory
> > and if there is an overlap, boot memory allocator should scream?
>
> Some x86 bootmem code right now relies on it not screaming (or at least not
> erroring out). That would need to be fixed first. Or you make it a flag.
> Would probably make sense, except that we already have too many bootmem
> allocation variants :/
Ok, I made a flag, see the next version of the patch.
Thanks,
Bernhard
* Vivek Goyal <[email protected]> [2007-10-16 07:49]:
>
> Shouldn't bootmem allocator have the functionality to flag an error if
> we try to reserve a memory which is already reserved? I see that bootmem
> allocator is currently printing a warning under CONFIG_DEBUG_BOOTMEM.
That's probably better, yes. See the next version.
> Wouldn't it be better if we reserve the code, data and bss memory also
> using bootmem allocator and when somebody tries to reserve craskernel memory
> and if there is an overlap, boot memory allocator should scream?
It's already marked as reserved. At least on i386 in my test.
> In second patch, you are checking for crash kernel reserved memory being
> beyond _end. That will make sure that there is no overlap with kernel
> text, data or bss. I am wondering then why do we need first patch and
> why should we register bss memory in the resources list. Second patch
> would make sure that there is no overlap with crash kernel memory and kexec
> will not place any segment outside crashkernel memory.
I think we should also present the BSS to the user like we present
text and data.
Thanks,
Bernhard