linux-kernel - Re: [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor

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]

Date:	Tue, 08 Apr 2008 12:09:41 -0700
From:	Mike Travis <travis@....com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Alexander van Heukelum <heukelum@...lshack.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, heukelum@...tmail.fm
Subject: Re: [PATCH 1/2] boot: increase stack size for kernel boot loader
 decompressor

Ingo Molnar wrote:
> * Mike Travis <travis@....com> wrote:
> 
>> Ingo Molnar wrote:
>>> * Alexander van Heukelum <heukelum@...lshack.com> wrote:
>>>
>>>> Hi Ingo,
>>>>
>>>> I see you have applied the following patch to x86#for-akpm. It was 
>>>> really ment for testing only. I think you ment to use this one 
>>>> instead?
>>> yep, i wanted to see how it holds up in testing - it's OK so far. I've 
>>> got your other, fuller one queued up meanwhile - it's not pushed out 
>>> yet.
>>>
>>> 	Ingo
>> I will try it out on my failing case as soon as I can...
> 
> more test results: i just booted an allyesconfig 64-bit (MAXSMP, etc.) 
> kernel on x86 native hardware successfully - that has Alexander's patch 
> included but not your boot tweak. (has all your other patches included)
> 
> would you expect a real 4K CPUs system to boot any differently? So early 
> during bootup all x86 hardware is just a uniprocessor, so i'd be 
> surprised if there was any difference.
> 
> [ in any case, if the tweak still makes a real difference for you we can 
>   still apply it because it does not hurt anyone - but lets try to avoid 
>   black voodoo tweaks as much as possible :) ]

Yes, my patch is not needed.  I booted the akpm2 config with 512 possible
cpus (8 real) on an Intel box with 8gig total ram.  It booted fine and is
running some cpuset and sched-domain tests now.

One problem though, even though it has slots for extra cpus to be brought
online there is no /sys/devices/cpu/cpuXX/online file to actually bring
them online.  This was shown in a simulated run I did with 64 real cpus
and 12 of them disabled.  They showed up in the 'possible' map but no
way to bring them online.  [Unless there's a trick I don't know about.
Nothing is mentioned in Documentation/cpu-hotplug.txt about this.]

> 
> btw,. booting up MAXSMP is pretty impressive:
> 
>   CONFIG_NR_CPUS=4096
> 
> shows how far Linux scalability has come :)
> 
> i've got a bugreport for you though: MAXSMP does not suspend+resume 
> correctly ;-) It gets this far:
> 
> [  146.348790] PM: Syncing filesystems ... done.
> [  146.353488] PM: Preparing system for mem sleep
> [  146.360204] Freezing user space processes ... (elapsed 0.00 seconds) done.
> [  146.367172] Freezing remaining freezable tasks ... (elapsed 0.93 seconds) done.
> [  147.309618] PM: Entering mem sleep
> [  147.313032] Suspending console(s)
> 
> then reboots spontaneously instead of resuming. (I use the 
> suspend+resume self-test feature below to conduct automated 
> suspend/resume tests.)
> 
> 	Ingo

I will try it out.  Yes, please send me any tests I can add to my suite.

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/