linux-kernel - Re: [PATCH RFC] Simplify the Linux kernel by reducing its state space

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: <20120331223200.GA32482@n2100.arm.linux.org.uk>
Date:	Sat, 31 Mar 2012 23:32:00 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, linux-alpha@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	uclinux-dist-devel@...ckfin.uclinux.org,
	linux-hexagon@...r.kernel.org, linux-ia64@...r.kernel.org,
	linux-m32r@...linux-m32r.org, linux-m32r-ja@...linux-m32r.org,
	linux-mips@...ux-mips.org, linux-am33-list@...hat.com,
	linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
	linux-s390@...r.kernel.org, linux-sh@...r.kernel.org,
	sparclinux@...r.kernel.org, tglx@...utronix.de,
	dhowells@...hat.com, jejb@...isc-linux.org, linux390@...ibm.com,
	x86@...nel.org, cmetcalf@...era.com
Subject: Re: [PATCH RFC] Simplify the Linux kernel by reducing its state
	space

On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:
> Although there have been numerous complaints about the complexity of
> parallel programming (especially over the past 5-10 years), the plain
> truth is that the incremental complexity of parallel programming over
> that of sequential programming is not as large as is commonly believed.
> Despite that you might have heard, the mind-numbing complexity of modern
> computer systems is not due so much to there being multiple CPUs, but
> rather to there being any CPUs at all.  In short, for the ultimate in
> computer-system simplicity, the optimal choice is NR_CPUS=0.
> 
> This commit therefore limits kernel builds to zero CPUs.  This change
> has the beneficial side effect of rendering all kernel bugs harmless.
> Furthermore, this commit enables additional beneficial changes, for
> example, the removal of those parts of the kernel that are not needed
> when there are zero CPUs.
> 
> Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> Reviewed-by: Thomas Gleixner <tglx@...utronix.de>

Great work, but I don't think you've gone far enough with this.

What would really help is if you could consolidate all these NR_CPUS
definitions into one place so we don't have essentially the same thing
scattered across all these architectures.  We're already doing this on
ARM across our platforms, and its about time such an approach was taken
across the entire kernel tree.

It looks like the MIPS solution would be the best one to pick.
Could you rework your patch to do this please?

While you're at it, you might like to consider that having zero CPUs
makes all this architecture support redundant, so maybe you've missed
a trick there - according to my count, we could get rid of almost 3
million lines of code from arch.  We could replace all that with a
single standard implementation.

Bah, maybe I shouldn't have pushed that bpf_jit code for ARM after all...
--
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/