CONFIG_DEBUG_STACKOVERFLOW hurts
Gilboa Davara
gilboad at gmail.com
Fri Sep 14 22:34:24 UTC 2007
On Tue, 2007-09-11 at 15:05 -0500, Eric Sandeen wrote:
> 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,
>
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.
More information about the Fedora-kernel-list
mailing list