Re: 4k stacks in 2.6

[Jörn Engel]

On Wed, 26 May 2004 12:33:03 +0200, Ingo Molnar wrote:
> * Andrea Arcangeli <andrea@xxxxxxx> wrote:
> > On Tue, May 25, 2004 at 04:10:29PM -0400, Rik van Riel wrote:
> > > Fragmentation causes fork trouble (gone with the 4k stacks)
> > 
> > btw, the 4k stacks sounds not safe to me, most people only tested with
> > 8k stacks so far, I wouldn't make that change in a production tree
> > without an unstable cycle of testing in between. I'd rather risk a an
> > allocation failure than a stack memory corruption.
> 
> 4k stacks is a cool and useful feature and tons of effort that went into
> making them as safe as possible. Sure, we couldnt fix up bin-only
> modules, but all the kernel drivers are audited for stack footprint, and
> many months of beta testing has gone into this as well. Anyway, if you
> prefer you can turn on 8k stacks - especially if you tree has lots of
> not-yet-upstream driver patches.
> 
> > x86-64 has per-irq stacks that allowed to reduce the stack size to 8k
> > (which is very similar to 4k for an x86, but without per-irq stack
> > it's too risky).
> 
> do you realize that the 4K stacks feature also adds a separate softirq
> and a separate hardirq stack? So the maximum footprint is 4K+4K+4K, with
> a clear and sane limit for each type of context, while the 2.4 kernel
> has 6.5K for all 3 contexts combined. (Also, in 2.4 irq contexts pretty
> much assumed that there's 2K of stack for them - leaving a de-facto 4K
> stack for the process and softirq contexts.) So in fact there is more
> space in 2.6 for all, and i dont really understand your fears.

Experience indicates that for whatever reason, big stack consumers for
all three contexts never hit at the same time.  Big stack consumers
for one context happen too often, though.  "Too often" may be quite
rare, but considering the result of a stack overflow, even "quite
rare" is too much.  "Never" is the only acceptable target.

Change gcc to catch stack overflows before the fact and disallow
module load unless modules have those checks as well.  If that is
done, a stack overflow will merely cause a kernel panic.  Until then,
I am just as conservative as Andreas.

Jörn

-- 
And spam is a useful source of entropy for /dev/random too!
-- Jasmine Strong
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/