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: <469CD456.801@gmail.com>
Date:	Tue, 17 Jul 2007 16:38:14 +0200
From:	Rene Herman <rene.herman@...il.com>
To:	Bodo Eggert <7eggert@....de>
CC:	Ray Lee <ray-lk@...rabbit.org>, Matt Mackall <mpm@...enic.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Jesper Juhl <jesper.juhl@...il.com>,
	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 07/17/2007 12:06 PM, Bodo Eggert wrote:

> On Tue, 17 Jul 2007, Rene Herman wrote:
>> On 07/17/2007 01:45 AM, Bodo Eggert wrote:

>>> You claim 4k+4k is safe, therefore 8k must be safe, too.
>> 
>> No, I most certainly do not. I claim proving that 4K and seperate (per cpu) 
>> interrupt stacks are safe are exactly the same as proving unshared 8K stacks 
>> are safe. That is, you don't, no such proof exists other than in the eating 
>> of the pudding.
> 
> And yet you have a more strict claim than I do. If you are right, I'll be
> right, too, because two times less-than-4K is less tham 8K.

Firstly, it's not two times 4K but 4K + (4K + 4K) * NR_CPUS. Secondly, _you_ 
are the one making claims -- specifically that !CONFIG_4KSTACKS is "safer", 
happily ignoring the fact that generally speaking available process stack 
can be _better_ with CONFIG_4KSTACKS and there seems to exist but _one_ 
(één, ein, une) known situation where it's problematic.

Must there be none rather than one? In some senses maybe, if the problem is 
more than bad, fixable code but I doubt you know this. CONFIG_4KSTACKS is 
much better on the VM (and hence faster) and as such, any user not using the 
one nicely isolated and identified problem case benefits from it. This means 
it's either very close or already _at_ the point of being the best default 
for the kernel. Changing options is for users with special needs, as you 
believe you are.

I truly apologise for taking it into this direction but you're wearing me 
down rapidly. Every single time you insert some uninformed crap comment that 
shows that you both don't understand the issue and didn't understand what 
the other person was saying and then after being made aware of such, ignore 
that and follow up with the next uninformed crap comment. That is, you seem 
to care less about the issue then about the discussion and since for me it's 
quite the other way around I'm leaving it at that.

RedHat is the one with the actual data available, and they've been enabling 
4KSTACKS for quite some time now (with some of their users apparently 
unhappy about it but not many it would seem).

Jesper also already posted how he's going to proceed: lift 4K from debug 
status and submit it as default for -mm. As to the latter bit, unless I 
remember wrong, it already _was_ default in -mm for some time a while ago so 
Andrew no doubt has an informed opinion on how to proceed with that.

Rene.
-
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/