CONFIG_DEBUG_STACKOVERFLOW hurts

[Eric Sandeen]

I sent this same message to LKML a while ago, but thought I'd get it a
more targeted audience:

=========================
Noticed today that the combination of 4KSTACKS and DEBUG_STACKOVERFLOW
config options is a bit deadly.

DEBUG_STACKOVERFLOW warns in do_IRQ if we're within THREAD_SIZE/8 of the
end of useable stack space, or 512 bytes on a 4k stack.

If we are, then it goes down the dump_stack path, which uses most, if
not all, of the remaining stack, thereby turning a well-intentioned
warning into a full-blown catastrophe.

The callchain from the warning looks something like this, with stack
usage shown as found on my x86 box:

4 dump_stack
4   show_trace
8     show_trace_log_lvl
4       dump_trace
          print_context_stack
12          print_trace_address
              print_symbol
232             __print_symbol
164               sprint_symbol
20                  printk
___
448

448 bytes to tell us that we're within 512 bytes (or less) of certain
doom... and I think there's call overhead on top of that?

The large stack usage in those 2 functions is due to big char arrays, of
size KSYM_NAME_LEN (128 bytes) and KSYM_SYMBOL_LEN (223 bytes).

IOW, the stack warning effectively reduces useful stack left in our itty
bitty 4k stacks by over 10%.

...

=========================


In light of this, I'd like to propose that we turn off
DEBUG_STACKOVERFLOW in Fedora, at least on x86/4KSTACKS.  I think it
does more harm than good; the warning is going to turn deadly most of
the time.

I also had sent a patch to LKML to print whether or not the stack was
overflowing, or had ever overflowed, on a kernel panic.  It's not yet
been merged.

... any comments?  I can file a bug but thought some discussion might be
in order.

Thanks,

-Eric