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 _______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-kernel-list