Messages in this thread | | | Date | Thu, 30 Aug 2007 00:53:56 +0200 | From | "Jesper Juhl" <> | Subject | Re: 4KSTACKS + DEBUG_STACKOVERFLOW harmful |
| |
On 30/08/2007, Eric Sandeen <sandeen@redhat.com> wrote: > 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. > ... > > 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%. > > Any suggestions for ways around this? The warning is somewhat helpful, > and I guess the obvious option is to lighten up the dump_stack path, but > it's still effectively reducing precious available stack space by some > amount. > A first step could be to allocate those two char arrays with kmalloc() instead of on the stack, but then I guess that dump_stack() gets called from places where we may not really want to be calling kmalloc(). I guess we could allocate the buffers earlier (like at boot time) and store pointers somewhere where dump stack can get to them later when it needs them.
> With CONFIG_DEBUG_STACK_USAGE, we could print at oops time: "oh, and by > the way, you blew your stack" if there is no zeroed stack space left, as > a post-mortem. Even without that option, I think we could still check > whether the *current* %esp at oops time has gone too far? But if we > blew the stack, returned, and *then* oops, I think it'd be hard to know > without the DEBUG_STACK_USAGE option that we ran out of room. >
We could also simply have it warn at a higher limit, like 1024 bytes instead of 512. But I guess then we would get too many false positives and make it less useful.
-- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |