linux-kernel - Re: [GIT PULL] core kernel update

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: <20131119190904.GA22076@gmail.com>
Date:	Tue, 19 Nov 2013 20:09:04 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Josh Boyer <jwboyer@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Josh Boyer <jwboyer@...oraproject.org>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [GIT PULL] core kernel update


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Tue, Nov 19, 2013 at 7:42 AM, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > Josh Boyer (1):
> >       smp/cpumask: Make CONFIG_CPUMASK_OFFSTACK=y usable without debug dependency
> 
> This seems to be just pure stupid.
> 
> Why the hell should we ever ask the user whethr they want to force 
> CPUMASK offstack?
> 
> Seriously, it only leaves room for mistakes and stupidities. There 
> is no reason for any normal use-case to ask the user about this. 
> Even the help message is pure and utter garbage ("This is a bit more 
> expensive, but avoids stack overflow").
> 
> The fact is, an on-stack CPUMASK is *smaller* than a pointer to an 
> offstack one when NR_CPU is small. The question makes no sense then. 
> And when NR_CPU is huge, the question makes no sense _either_, since 
> we can't have the cpumasks on stack.

You are completely right. I missed that, will fix it up.

So we have these CPU count ranges right now:

  config NR_CPUS
        int "Maximum number of CPUs" if SMP && !MAXSMP
        range 2 8 if SMP && X86_32 && !X86_BIGSMP
        range 2 512 if SMP && !MAXSMP && !CPUMASK_OFFSTACK
        range 2 8192 if SMP && !MAXSMP && CPUMASK_OFFSTACK && X86_64

As you pointed out offstack is definitely nonsensical for
NR_CPUS <= 64. (on 64-bit CPUs) On-stack is known to crash with 
NR_CPUS >= 1024.

The 128..512 CPUs range is somewhat of an unknown.

So the fixed code would always use on-stack cpumasks up to a limit 
(which limit falls into the 128...512 range) and it would always use 
off-stack cpumasks above that limit. No user configurability in the 
regular case. [*]

The actual value of the limit - here's the on-stack cpumask sizes of 
the candidate range:

	128 CPUs: 16 byte cpumasks
	256 CPUs: 32 byte cpumasks
	512 CPUs: 64 byte cpumasks

512 definitely 'feels' dangerous, so I'd say the limit should be 
either 128 or 256. Both are ridiculously high counts for regular 
systems, so it doesn't really matter which one we pick.

I'd guess we should pick the higher limit for the time being (256 CPUs 
- maybe even 512 CPUs), and lower it on contrary evidence (evidence of 
stack overflows)?

Thoughts?

Thanks,

	Ingo

[*] Plus perhaps allow offstack to be configurable arbitrarily if 
    debugging is enabled [DEBUG_PER_CPU_MAP=y], to allow easy
    experiments/measurements?
--
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/