[lkml]   [2005]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [2.6 patch] i386: always use 4k stacks
    El Fri, 23 Dec 2005 11:12:38 +0100,
    Bodo Eggert <> 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
    This patch ( 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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-12-23 15:01    [W:0.022 / U:19.188 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site