linux-kernel - Re: [block IO crash] Re: 2.6.39-rc5-git2 boot crashs

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] [day] [month] [year] [list]

Date:	Fri, 6 May 2011 00:27:20 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	werner <w.landgraf@...ru>
cc:	Christoph Lameter <cl@...ux.com>, Tejun Heo <tj@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Pekka Enberg <penberg@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	Jens Axboe <axboe@...nel.dk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [block IO crash] Re: 2.6.39-rc5-git2 boot crashs

On Thu, 5 May 2011, werner wrote:
> 90% of the config options, users don't know for what they are.  Instead of
> more and more new config features in, EVERY CONFIG PARAMETER WHAT THE KERNEL
> CAN DETECT AT RUN TIME (at the beginning of booting) SHOULD BE THROWED OUT.
> And the kernel should be compiled 'everythingyes' as default.   Even then,
> with all exotic (but nowadays happening) boot-necessary input/output hardware
> included, my vmlinuz is only 10 MB big.   Sufficient memory for run this
> (together with an initrd for an installer) nowadays should exist on almost all
> computers.  All other, not-boot necessary modules are perhaps 50 MB, and since
> the Atari time with 20 MB harddisks passed, there is NO REASON FOR COMPILE
> SMALL THE KERNEL. Even on Android phones, compiling the kernel / modules 50 MB
> big but using often only a part, dont hurt. But for emergency, instead of
> completely configless, one could let 2 options for the kernel config:  normal,
> small (below 16 M memory).   Provisorically, one could but one should not
> include such a raw-selection menu in the kernel config, because to check and
> maintain the dependences of their various single config parameters would be
> big extra work.   Instead of this, one should rigorously make more and more
> config parameters definitively obsolete and reduce them by improving the
> corresponding runtime ability of the kernel.

Have a look outside of the x86 and "smartphone brag with your GBs of
RAM" world and you'll see that there are 

  - systems which really care about size reductions which are measured
    in kilobytes.

  - systems where runtime detection is impossible

  - systems where runtime detection is complete overkill in various
    aspects: boottime, memory footprint ...  

And you CANNOT put those requirements under a single CONFIG_VERY_SMALL=y
fits it all thing simply because embedded devices have those fundamental
different requirements vs. drivers, filesystems ....

Aside of that config options are a pretty useful mechanism to debug
problems.

And in the context of that particular case you are barking up the
completely wrong tree. The facts that

 - slub used the wrong macro

 - the CONFIG dependent x86 implementation of that this_cpu_* mess was
   crap to begin with

are not an argument at all to go and impose a 100MB/50MB/16MB or
whatever arbitrary choice you make limit of CONFIG_FITS_IT_ALL_*
approach.

That simply does not work.

Thanks,

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