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.025 / U:30.112 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site