Gilboa Davara wrote: > 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. Well, I agree that the dump_stack path should be lightened up stack-wise; and I don't think performance should be an issue (dump_stack is used when something has gone wrong, probably not going to be performance critical?) Locked global buffers may be just fine (we did this for xfs error messages, I remember...) 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). 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. So, what's the point of the IRQ stack-depth check, again? Especially with 4k stacks and separate IRQ stacks? And the more deterministic max-stack-depth excursion checker (CONFIG_DEBUG_STACK_USAGE) as well... Finally, the patch I sent upstream would clearly show on an oops whether or not the stack was currently overflowing, or whether the stack had ever overflowed prior to the oops. Seemed useful to me. -Eric _______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-kernel-list
