lkml.org 
[lkml]   [2008]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor
On Mon, Apr 07, 2008 at 11:14:16AM -0700, Mike Travis wrote:
> Alexander van Heukelum wrote:
> > On Fri, Apr 04, 2008 at 06:30:15PM -0700, Mike Travis wrote:
> >> * Increase stack size for the kernel bootloader decompressor. This is
> >> needed to boot a kernel with NR_CPUS = 4096. I tested with 8k stack
> >> size but that wasn't sufficient.
> >>
> >> Based on:
> >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> >> + x86/latest .../x86/linux-2.6-x86.git
> >> + sched-devel/latest .../mingo/linux-2.6-sched-devel.git
> >>
> >> Signed-off-by: Mike Travis <travis@sgi.com>
> >> ---
> >> arch/x86/boot/compressed/head_64.S | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> --- linux-2.6.25-rc5.orig/arch/x86/boot/compressed/head_64.S
> >> +++ linux-2.6.25-rc5/arch/x86/boot/compressed/head_64.S
> >> @@ -314,5 +314,5 @@ gdt_end:
> >> /* Stack for uncompression */
> >> .balign 4
> >> user_stack:
> >> - .fill 4096,4,0
> >> + .fill 16384,4,0
> > --------------^^^ * ^
> >
> > Changed from 16K to 64K. I wonder what is using so much space on
> > this stack?
> >
> >> user_stack_end:
> >>
> >> --
>
> Hi,
>
> That is a good question. It's pretty difficult to debug at that early
> stage (any ideas are certainly welcome!). It's mostly hit and miss (and
> handy access to the reset button ;-) I could do some further research
> but since it's "throwaway" memory (at least I think it is), then I didn't
> think it important to pursue.

It's certainly not important enough to put much time in. I tried
MAXSMP on top of just Ingo's -x86 with qemu, though, but it wouldn't
crash. I set the stack size to 16 bytes, and it still booted happily
(of course there is still about 11 kilobytes of inflate code which
is then overwritten by stack use).

I did see that the malloc space that the inflate code is using is
taken from _after_ the end of the bss. I don't see how this is
protected from being used/overwritten. Changing the stack size changes
the memory layout a bit... maybe you were so unlucky to create a
vmlinux image that was just barely smaller than some threshold and
increasing the stack size made the decompression/relocation area be
located somewhere else?

Test patch follows.

Greetings,
Alexander

> Thanks,
> Mike

diff --git a/arch/x86/boot/compressed/vmlinux_32.lds b/arch/x86/boot/compressed/vmlinux_32.lds
index bb3c483..c858e30 100644
--- a/arch/x86/boot/compressed/vmlinux_32.lds
+++ b/arch/x86/boot/compressed/vmlinux_32.lds
@@ -39,5 +39,6 @@ SECTIONS
*(.bss.*)
*(COMMON)
_end = . ;
+ _real_end = . + 0x4000;
}
}
diff --git a/arch/x86/boot/compressed/vmlinux_64.lds b/arch/x86/boot/compressed/vmlinux_64.lds
index 7e5c720..9bef3cd 100644
--- a/arch/x86/boot/compressed/vmlinux_64.lds
+++ b/arch/x86/boot/compressed/vmlinux_64.lds
@@ -44,5 +44,6 @@ SECTIONS
pgtable = . ;
. = . + 4096 * 6;
_heap = .;
+ _heap_end = . + 0x7000;
}
}


\
 
 \ /
  Last update: 2008-04-07 23:51    [W:0.780 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site