On Fri, 2007-09-21 at 17:02 +0100, Paulo Marques wrote: > 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. >
OK. I'll wait for additional comments while thinking about a third route. (Following your suggestion) - Gilboa - 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/
