Re: [tip:tracing/urgent] tracing: Fix too large stack usage indo_one_initcall()

[Andrew Morton]

On Fri, 21 Aug 2009 13:14:50 +0200 Ingo Molnar <mingo@xxxxxxx> wrote:

> 
> ...
>
> btw., it will just take two more features like kmemleak to trigger 
> hard to debug stack overflows again on 32-bit. We are right at the 
> edge and this situation is not really fixable in a reliable way 
> anymore.
> 
> So i think we should be more drastic and solve the real problem: we 
> should drop 4K stacks and 8K combo-stacks on 32-bit, and go 
> exclusively to 8K split stacks on 32-bit.

We seem to have overrun an 8k stack in
http://bugzilla.kernel.org/show_bug.cgi?id=14029

Do we have a max-stack-depth tracer widget btw?

> I.e. the stack size will be 'unified' too between 64-bit and 32-bit 
> to a certain degree: process stacks will be 8K on both 64-bit and 
> 32-bit x86, IRQ stacks will be separate. (on 64-bit we also have the 
> IST stacks for certain exceptions that further isolates things)
> 
> This will simplify the 32-bit situation quite a bit and removes a 
> contentious config option and makes the kernel more robust in 
> general. 8K combo stacks are not safe due to irq nesting and 4K 
> isolated stacks are not enough. 8K isolated stacks is the way to go.
> 
> Opinions?

I wouldn't lose any sleep over it.

I bet it would be sufficient to have 4k interrupt stacks though.

My main concern would be maintenance.  Over time we'll chew more and
more stack space and eventually we'll get into trouble again.  What
means do we have for holding the line at 8k, and even improving things?


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