On Wed, Feb 28, 2007 at 09:41:44PM +0100, Andi Kleen wrote: > Likely already too late then -- if critical state is overwritten > you crashed before. Also a lot of stack intensive codes > relatively large unused holes so it might miss the canary completely > Anyways if you want a crash on context switch in the non > hole case you can probably get it by just rearranging thread_info a bit. > e.g. put preempt_count first. Any corruption of that will lead > to schedule complaining. > Don't think it is worth it though. > I suppose one could have a CONFIG_DEBUG_STACK_OVERFLOW that gets > the stacks from vmalloc which would catch any overflow with its > guard pages. This is you would need to change __pa() to handle > that too because there might be still some drivers that do > DMA on stack addresses. Would be somewhat ugly but doable. > But I have my doubts it is worth it again -- in my experience static > analysis works well enough to trace them down and > there are not that many anyways.
I don't know about the rest of the world, but halting the system in the case of memory corruption sounds like an extremely good idea to me. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
