linux-kernel - Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?

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: <9a8748490707161554j1fa7625fq1f1cb7e6aa359715@mail.gmail.com>
Date:	Tue, 17 Jul 2007 00:54:46 +0200
From:	"Jesper Juhl" <jesper.juhl@...il.com>
To:	"Ray Lee" <ray-lk@...rabbit.org>
Cc:	"Rene Herman" <rene.herman@...il.com>,
	"Bodo Eggert" <7eggert@....de>, "Matt Mackall" <mpm@...enic.com>,
	"Jeremy Fitzhardinge" <jeremy@...p.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"William Lee Irwin III" <wli@...omorphy.com>,
	"David Chinner" <dgc@....com>,
	"Arjan van de Ven" <arjan@...radead.org>
Subject: Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?

On 17/07/07, Ray Lee <ray-lk@...rabbit.org> wrote:
> On 7/16/07, Rene Herman <rene.herman@...il.com> wrote:
> > Seeing as how single-page stacks are much easier on the VM so that creating
> > those zillion threads should also be faster, at _some_ percentage we get to
> > say "and now to hell with the rest".
>
> This is the core dispute here. Stated differently, I hope you never
> design a bridge that I have to drive over.
>
> Correctness first, optimization second. Introducing random and
> difficult to trace crashes upon an unsuspecting audience of sysadmins
> and users is not a viable option.
>
> If at some point one of the pro-4k stacks crowd can prove that all
> code paths are safe, or introduce another viable alternative (such as
> Matt's idea for extending the stack dynamically), then removing the 8k
> stacks option makes sense.
>

Please note that I was not trying to remove the 8K stack option right
now - heck, I didn't even add anything to feature-removal-schedule.txt
- all I wanted to accomplish with the patch that started this threas
was;  a) indicate that the 4K option is no longer a debug thing  and
b) make 4K stacks the default option in vanilla kernel.org kernels as
a gentle nudge towards getting people to start fixing the code paths
that are not 4K stack safe.
Distros that currently use 8K stacks can continue to do so just fine,
individuals compiling their own kernel.org kernels can as well and
people using oldconfig wouldn't get any change, only people
configuring a new kernel.org kernel from scratch would see a change.
It was mostly meant as a hint that we want to move in the 4K stack
direction over time...
In the future (perhaps far future) when all 4K unsafe codepaths are
believed to have been fixed an entry could be made in
feature-removal-schedule.txt stating that the 8K option would go away
in 6, 12 or whatever, months.   That was my intention with the patch I
posted, I never intended to rip out 8K stacks anytime *soon*.


-- 
Jesper Juhl <jesper.juhl@...il.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html
-
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/