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: <488E06F0.4070404@sgi.com>
Date:	Mon, 28 Jul 2008 10:50:40 -0700
From:	Mike Travis <travis@....com>
To:	Rusty Russell <rusty@...tcorp.com.au>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [git pull] cpus4096 fixes

Rusty Russell wrote:
> On Monday 28 July 2008 06:15:26 Linus Torvalds wrote:
>> On Sun, 27 Jul 2008, Ingo Molnar wrote:
>>> Please pull the latest cpus4096-fixes git tree from:
>> No. Not without explanations.
>>
>> Quite frankly, this "fix" looks like a huge stinking pile of sh*t.
>>
>> I can't follow that thread on lkml.org (horrible web interface with
>> hard-to-follow threading), and I'm too lazy to bother to look in my lkml
>> email archives, but whoever said
>>
>>   "The simple version is just a static array of [NR_CPUS] cpumask_t's."
>>
>> and then implemented this piece of shit is a complete and utter moron.
> 
> How awesome, Linus is talking about me!
> 
> Your idea is clever, thanks.  This patch was a bandaid to save us from the 
> unbearably fugly "cpumask_of_cpu_ptr_declare(cpu_mask)".  I was going to rip 
> this code out as soon as possible, but with your trick we should keep it.
> 
> The 4k CPU patches have been sliding in without review up until now.  We need 
> a serious think about how to handle cpumask_t that doesn't fit on the stack.  
> 
> Hey, since Mike put his Signed-off-by above mine and didn't put a From line 
> when he took my patch, WFT am I taking responsibility? :)
> 
> Rusty.

Sorry, I didn't know that was the protocol.  And yes, the clever idea of
compacting the memory is a good one (wish I would have thought of it... ;-)
But, and it's a big but, if you really have 4096 cpus present (not NR_CPUS,
but nr_cpu_ids), then 2MB is pretty much chump change.

But I'll redo the patch again.  And look for more space saving areas.  As
for the goal of these patches, it was to lessen the impact as much as possible
on smaller systems so that the distros can set the default NR_CPUS=4096 in
their binary (validated, certified, licensable) kernels.  This is a huge
priority to our customers.  Please keep telling me where I'm going wrong at
this.

Thanks for the comments and feedback.
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