* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 21 Aug 2009, Andrew Morton wrote: > > > > We seem to have overrun an 8k stack in > > http://bugzilla.kernel.org/show_bug.cgi?id=14029 Note that's a 32-bit 8K stack oops, so it doesnt apply. > The thread "v2.6.31-rc6: BUG: unable to handle kernel NULL pointer > dereference at 0000000000000008" also has at least one oops that > has that "Thread overran stack, or stack corrupted" marker thing. This is a 64-bit one, a pty related one and it's not yet clear what happened there - but it's certainly possible to overrun any stack. > > My main concern would be maintenance. Over time we'll chew more > > and more stack space and eventually we'll get into trouble > > again. What means do we have for holding the line at 8k, and > > even improving things? > > That's why I think the async thing could fix this - if we _force_ > async calls to be asynchronous, you won't have the deep callchains > for all the device discovery thing. Agreed. OTOH we have deep callchains in things like execve() too which seem to be a lot harder to fix - and those have been around for the past ~10 years since i've been looking at max-stacktraces. I think 4K doesnt cut it anymore. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|