CONFIG_DEBUG_STACKOVERFLOW hurts

[Eric Sandeen]

Gilboa Davara wrote:

>> 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).
> 
> While it is true,
> A. If adding ~40 bytes to the kernel's stack usage is critical, we're
> already passed the all-doom-and-gloom-point.

Though, just to play devil's advocate, say your absolute worst case
stack depth goes to within 35 bytes of the end.  The warning (even if
trimmed down to 40 bytes) now renders your system unstable in the long
run.  Why waste it?

> B. We can always calculate the available stack size, and if stack_remain
> is bigger then say, 80 bytes, call dump_stack.

That seems reasonable.  Today, the dump_stack depth ~= the warning
threshold, so it's just broken and pointless as it stands.

>> 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.  
> 
> Yeah, but at least to me, as a developer, having a warning before
> all-hell-breaks-lose, is a good thing (tm). 

Perhaps.  The current warning is fairly random, anyway, since it only
fires on an IRQ.  If you randomly get the warning at your max stack
excursion, but never go so far as to actually blow the stack, then you
really didn't need the warning, did you?  If you get the warning at
maybe 85% of your stack excursion, then your thread continues post-IRQ
and blows the stack, you get a nice backtrace anyway and the warning
didn't help much.  I'm still not convinced that it's that useful.

I like the CONFIG_DEBUG_STACKUSAGE which accurately tells you what your
max stack excursions have been.   I just wish it could tell you what the
callchain *was* (not really possible, as it's written) - and making it
resettable would be nice too (easy).

-Eric