linux-kernel - Re: [git pull] cpus4096 tree, part 3

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:	Sat, 3 Jan 2009 12:56:03 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Rusty Russell <rusty@...tcorp.com.au>,
	Mike Travis <travis@....com>, linux-kernel@...r.kernel.org
Subject: Re: [git pull] cpus4096 tree, part 3

On Sat, 3 Jan 2009, Ingo Molnar wrote:
> 
> > Has anybody looked at what the stack size is with MAXSMP set with an 
> > allyesconfig? And what areas are still problematic, if any? Are we going 
> > to have some code-paths that still essentially have 1kB+ of stack space 
> > just because they haven't been converted and still have the cpu mask on 
> > stack?
> 
> ok, indeed testing of that is in order now.

Well, since I can compile a allyesconfig pretty quickly, I did the static 
part. It looks better than it used to, and I think most of the huge stacks 
are totally unrealted to cpu masks. But not all.

But it looks like we have a few:

 - flush_tlb_current_task:
	cpumask_t cpu_mask;
 - flush_tlb_mm:
	cpumask_t cpu_mask;
 - local_cpus_show:
	cpumask_t mask;
 - local_cpulist_show:
	cpumask_t mask;
 - acpi_cpufreq_target:
	cpumask_t online_policy_cpus

and then we have a number of things that have "struct cpufreq_policy" on 
the stack, and those things have two cpumask_t's in each.

The rest of the high-stack-usage cases - from a _very_ quick look - seem 
to be unrelated to CPU masks, but in the "more than 1kB of stack" group 
about a third (wild handwaving eyeballing) of them do seem to be related 
to cpumask.

And those things (VM, ACPI and PCI) are easily triggered in real use and 
don't need odd hardware. So I think they need to be fixed before 2.6.29, 
otherwise I'll have to disable MAXSMP and again limit MAX_CPU back to 128 
or something.

			Linus
--
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/