linux-kernel - Re: x86: 4kstacks default

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: <20080420132113.GA1899@cs181133002.pp.htv.fi>
Date:	Sun, 20 Apr 2008 16:21:13 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Willy Tarreau <w@....eu>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Shawn Bohrer <shawn.bohrer@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: x86: 4kstacks default

On Sun, Apr 20, 2008 at 02:47:17PM +0200, Willy Tarreau wrote:
>...
> I certainly can understand that reducing memory footprint is useful, but
> if we want wider testing of 4k stacks, considering they may fail in error
> path in complex I/O environment, it's not likely during -rc kernels that
> we'll detect problems, and if we push them down the throat of users in a
> stable release, of course they will thank us very much for crashing their
> NFS servers in production during peak hours.

I've seen many bugs in error paths in the kernel and fixed quite a 
few of them - and stack problems were not a significant part of them.

There are so many possible bugs (that also occur in practice) that 
singling out stack usage won't gain much.

> I have nothing against changing the default setting to 4k provided that
> it is easy to get back to the save setting (ie changing a config option,
> or better, a cmdline parameter). I just don't agree with the idea of
> forcing users to swim in the sh*t, it only brings bad reputation to
> Linux.
>...

What actually brings bad reputation is shipping a 4k option that is 
known to break under some circumstances.

And history has shown that as long as 8k stacks are available on i386 
some problems will not get fixed. 4k stacks are available as an option 
on i386 for more than 4 years, and at about as long we know that there 
are some setups (AFAIK all that might still be present seem to include 
XFS) that are known to not work reliably with 4k stacks.

If we go after stability and reputation, we have to make a decision 
whether we want to get 4k stacks on 32bit architectures with 4k page 
size unconditionally or not at all. That's the way that gets the maximal 
number of bugs shaken out [1] for all supported configurations before 
they would hit a stable kernel.

> Willy

cu
Adrian

[1] obviously not all, but that's true for all classes of bugs

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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