lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47FA6478.1070301@sgi.com>
Date:	Mon, 07 Apr 2008 11:14:16 -0700
From:	Mike Travis <travis@....com>
To:	Alexander van Heukelum <heukelum@...lshack.com>
CC:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] boot: increase stack size for kernel boot loader
 decompressor

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@....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.

And thanks for the correction, I thought I was bumping a byte count, not
a word count.

Thanks,
Mike
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ