DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding;
        b=rOti+YSLy5O+Uvo+JMwTWnLJyZXIK5/A0JTd1DBd/lkfVHLJ1CT3kVZeb5QAKFo5ta7VJvEnHXa5DG1Nwy4RPjn2HJbGb8YPH6WvpmysYgPvmwjb/E6nMUu3NgFW35OWE+iXgMj8Cjl/eXJr7bd7w5Q1aJJQV6SO1sIvfwggx1U=
Date: Fri, 23 Dec 2005 14:59:10 +0100
From: Diego Calleja <diegocg@gmail.com>
To: 7eggert@gmx.de
Cc: harvested.in.lkml@7eggert.dyndns.org, vonbrand@inf.utfsm.cl,
       kernel-stuff@comcast.net, Dumitru.Ciobarcianu@iNES.RO,
       helge.hafting@aitel.hist.no, ak@suse.de, bunk@stusta.de,
       mrmacman_g4@mac.com, akpm@osdl.org, linux-kernel@vger.kernel.org,
       arjan@infradead.org
Subject: Re: [2.6 patch] i386: always use 4k stacks
Message-Id: <20051223145910.26ddcf17.diegocg@gmail.com>
In-Reply-To: <E1Epjug-0001iA-In@be1.lrz>
References: <5lQOU-492-31@gated-at.bofh.it>
	<5lQOU-492-29@gated-at.bofh.it>
	<E1Epjug-0001iA-In@be1.lrz>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2744
Lines: 57

El Fri, 23 Dec 2005 11:12:38 +0100,
Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org> escribi?:

> +               printk(KERN_WARNING, "Can't allocate new task structure"
> +#ifndef CONFIG_4KSTACKS
> +               ". Maybe you could benefit from 4K stacks.\n"
> +#endif
> +               "\

A sarcastic patch, nice. So, lets try to get something useful
from this flamewar...sight.


The 4k patch is being proposed for -mm. Personally I'm _shocked_ that so
many people is trying to avoid _testing_ (-mm is for testing, isn't it)
this feature so hard. Which is surprising, since merging it into -mm
may prove that they're right (people will report bugs caused by 4k
stacks, etc). Maybe 8k groupies are not willing to be proved that
they're right, or they're afraid of being proven that they're
wrong? </sarcasm>

Now, seriously:
I think that most of the 8k groupies don't like 4k not because it
doesn't works in the common case, but because it could cause hangs
that are not easy to reproduce (ie: they are paranoid). The combination
of code paths is too big and complex. I can understand that.

What I don't know is why you think that 8k will be "safe". As far
as I know, there're have been stacks overflows with 8KB stacks in
the past (ie, "hangs that are not easy to reproduce") before the 4k
stack patch was proposed, and the _one_ reason why now it's very
safe to run with 8k stacks is because the 4k stack patch has forced
people to do stack diets, not because 8k is the best option.

We have *NO* *WAY* of proving that it's safe to run either 4k or
8k stacks. Face it. And since such bugs can exist no matter what
stack size you use, the best option (IMO) is to choose the option that
will allow us to hit those bugs _faster_, ie: 4k stacks. From a
engineering point of view, I can't understand why hiding the problem
is better than choosing the path that will allow to hit and fix those
bugs faster. It remembers me of "security through obscurity". What 
we will do when we have too may overflows with 8K? 16K stacks? Oh,
let me guess: "we'll fix it"?. Well, and why can't we fix 4k stacks???

Now, the code is easy to maintain and some people depends on
8k stacks, as akpm pointed out in http://lkml.org/lkml/2005/12/15/336
This patch (http://lkml.org/lkml/2005/12/16/89) stolen from^W^Winspired
by Adrian Bunk defaults to 4k, makes the 8k people happy and it should
make akpm happy too.

Can someone tell me a reason why all this stupid flamewar can't be
solved with that patch?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/