Messages in this thread | | | Date | Thu, 10 Apr 2008 13:34:23 -0700 | From | "Yinghai Lu" <> | Subject | Re: [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor -- payload_length |
| |
On Tue, Apr 8, 2008 at 1:23 AM, Ingo Molnar <mingo@elte.hu> wrote: > > * Alexander van Heukelum <heukelum@mailshack.com> wrote: > > > 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. > > that's a really interesting theory. > > FWIIW, i've been booting allyesconfig bzImages for a long time (with > only minimal amount of drivers disabled - mostly old ISA ones that > assume the presence of the real hardware), and they boot and work fine > on both 32-bit and 64-bit typical whitebox PCs. That means huge bzImages > that decompresses into a ~41 MB kernel image. I'd expect that to be a > rather severe test of the decompressor.
payload_offset and payload_length in arch/x86/boot/head.S seems to be used by bootloader to seat the bzImage. or just use size of bzImage
and bootloader is supposed to load bzImage from 2M, and initrd near 4G...
so if you have memhole from [2M+36M, 2M+45M), and bzImage is only 10M, ...then you will have problem.
but I assume that bootloader already used bzImage size or payload size with
extra_bytes = (uncompressed_size >> 12) + 32768 + 18 + decompressor_size.
to get unzip size for good position for bzImage.
long term, should add one field after payload_length like payload_unzip_length to make bootloader or kexec what buffer size needed. YH
| |