CONFIG_DEBUG_STACKOVERFLOW hurts

[Eric Sandeen]

Gilboa Davara wrote:

> Sorry for butting in... but isn't disabling STACKOVERFLOW the wrong
> answer to this problem?
> Does anyone see any reason why both sprint_symbol and __print_symbol
> shouldn't use dynamically allocated buffers instead of wasting stack
> space? *
> 
> - GIlboa
> * If performance is an issue, memory can be statically allocated per CPU
> with additional locking in dump_trace. 

Well, I agree that the dump_stack path should be lightened up
stack-wise; and I don't think performance should be an issue (dump_stack
is used when something has gone wrong, probably not going to be
performance critical?)  Locked global buffers may be just fine (we did
this for xfs error messages, I remember...)

I was looking at this from a slightly different angle, which is that the
stack overflow warning is largely pointless - no matter how much you
lighten up the dump_stack path, it will add something to the stack depth
of the current process, effectively *reducing* the available stack for
all processes, and increasing the risk that you'll actually overflow.
(if you take an interrupt towards the end of the stack, the warning will
go off and use the last bit - so you can't count on that stack space to
be available).

And, if you overflow the stack, you'll almost certainly get an oops and
a backtrace anyway - usually thread_info gets overwritten and you BUG
because it looks like you sleep in an interrupt, or somesuch.  So,
what's the point of the IRQ stack-depth check, again?  Especially with
4k stacks and separate IRQ stacks?  And the more deterministic
max-stack-depth excursion checker (CONFIG_DEBUG_STACK_USAGE) as well...

Finally, the patch I sent upstream would clearly show on an oops whether
or not the stack was currently overflowing, or whether the stack had
ever overflowed prior to the oops.  Seemed useful to me.

-Eric