Messages in this thread | | | From | Kyle Moffett <> | Subject | Re: 4KSTACKS + DEBUG_STACKOVERFLOW harmful | Date | Wed, 29 Aug 2007 19:55:04 -0400 |
| |
On Aug 29, 2007, at 19:01:57, Eric Sandeen wrote: > Jesper Juhl wrote: >> A first step could be to allocate those two char arrays with >> kmalloc() instead of on the stack, but then I guess that dump_stack >> () gets called from places where we may not really want to be >> calling kmalloc(). I guess we could allocate the buffers earlier >> (like at boot time) and store pointers somewhere where dump stack >> can get to them later when it needs them. > > Yep, I thought about something like that... and I assume you'd need > a bit of locking around them too.
How about turning off preemption and using a per-CPU buffer? Alternatively you could turn off IRQs, poke a per-CPU value to clue in any incoming NMIs, and switch to a separate stack. I suppose if you wanted it to work with all of 16 bytes of stack left on both thread and IRQ stacks, you could have separate per-CPU NMI stacks; the stack-dump would be poking a special per-CPU value and sending ourselves an NMI.
There are probably a half dozen other variants on ways to run screaming to the CPU saying "It hurts mommy!" and get a new stack in which we can play for a while.
Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |