Messages in this thread | | | Date | Fri, 21 Sep 2007 17:02:29 +0100 | From | Paulo Marques <> | Subject | Re: [PATCH] Reduce __print_symbol/sprint_symbol stack usage. (v3) |
| |
Gilboa Davara wrote: > Hello all,
Hi, Gilboa
> (1) Problem: > I. When CONFIG_4KSTACKS and CONFIG_DEBUG_STACKOVERFLOW are enabled on > i386 kernels, do_IRQ calls dump_stack which, down the path, uses > print_symbol (display) and sprint_symbol (format) to format and display > the function name/address/module. > Both function use stack based char array (~350 bytes) that, given the > initial state (<512 bytes of stack space) may overrun the stack. > II. (Comments - previous patches) Using spinlock protected static > storage within these functions might block or even deadlock dump_stack > (E.g. Crash within dump_stack itself) > > (2) Solution: > I. Break sprint_symbol into sprint_symbol (API functions; keeps the > current interface) and sprint_symbol_helper (helper function with > minimal local storage). > II. Replace the char array in __print_symbol with two spinlock protected > static char arrays; call the __sprint_symbol helper function instead of > sprint_symbol. > III. Ignore the spinlock if oops_in_progress is set.
This is getting more and more convoluted :(
The problem with the spinlock isn't just that during a panic, we can not trust the kernel structures enough to use spinlocks. It might well happen that lockdep code might want to use print_symbol (and I think it does, so this is not just theoretical) to dump the stack when someone calls spin_lock_irqsave.
But now, because print_symbol itself uses spin_lock_irqsave, we might get into a recursive situation and a produce a deadlock.
On the other hand, if you take the other approach of reducing the stack usage by creating a printk_symbol interface, the stack usage would drop from 350 bytes to 128 bytes and your problem would go away entirely.
-- Paulo Marques - www.grupopie.com
"All I ask is a chance to prove that money can't make me happy." - 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/
| |