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]
Date:	Tue, 17 Jul 2007 02:57:45 +0200
From:	Rene Herman <rene.herman@...il.com>
To:	Ray Lee <ray-lk@...rabbit.org>
CC:	Bodo Eggert <7eggert@....de>, 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 01:40 AM, Ray Lee wrote:

> On 7/16/07, Rene Herman <rene.herman@...il.com> wrote:
>> On 07/17/2007 01:13 AM, Ray Lee wrote:
>> 
>> > Given that there's actual, y'know, reports of people who can easily
>> > crash a 4k+interrupt stacks kernel, and not an 8k one, I think the
>> > current evidence speaks for itself.
>>
>> Where?
> 
> The second message in this thread, according to my reader, from Zan
> Lynx. Another from Utz Lehmann a few minutes ago.

True enough. I'm rather wondering though why RHEL is shipping with it if 
it's a _real_ problem. Scribbling junk all over kernel memory would be the 
kind of thing I'd imagine you'd mightely piss-off enterprise customers with. 
But well, sure, that rather quickly becomes a self-referential argument I guess.

>> Removing any such option was not the objective of this thread, just 
>> lifting 4K stacks from debug and making it the default.
> 
> True, but your messages are reading as advocacy for removing the 8k
> option. I'm saying that's a bad idea. If I misunderstood your
> position, then my bad.

I personally believe that CONFIG_4KSTACKS is not better only for very few 
users but well, no, if even some users exist, then I wouldn't want to 
suggest they'd be disallowed (shared or unshared) 8K stacks.

I _would_ in fact suggest there are few enough left that rather than 4K, 8K 
should really be the option that only those few would select, but ofcourse, 
given config defaults that's mostly a matter of semantics, so who cares in 
the end.

> If they even realize that it's the cause of the problem. In the
> meantime, we're generating more bug reports to lkml. As the general
> opinion is that the ones getting received now aren't getting enough
> attention (see regression tracking threads), setting a default that is
> known to break setups in hard to debug ways seems counterproductive.

Well, no. "oldconfig" works fine, and other than that, all failure modes 
I've heard about also in this thread are MD/LVM/XFS. This is extremely 
widely tested stuff in at least Fedora and RHEL. "hard to debug" is simply 
not the case -- every one will immediately start yelling 4KSTACKS when that 
software-stack appears anywhere.

Don't try and hang this off generic development unease... ;-)

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ