On Wed, Feb 28, 2007 at 09:27:09AM -0500, Chuck Ebbert wrote: > Can we just put a canary in the threadinfo and check it on every > task switch? What are the drawbacks?
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. -Andi - 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/