On Thu, 2014-06-12 at 10:26 +0200, Jan Kara wrote: > On Wed 11-06-14 23:07:04, Sasha Levin wrote:
> > The first patch fixed it (I assumed that there's no need to try the second). > Good. So that shows that it is the increased lockdep coverage which is > causing problems - with my patch, lockdep is able to identify some problem > because console drivers are now called with lockdep enabled. But because > the problem was found in some difficult context, lockdep just hung the > machine when trying to report it... Sadly the stacktraces you posted don't > tell us what lockdep found. > > Adding Peter Zijlstra to CC. Peter, any idea how lockdep could report > problems when holding logbuf_lock? One possibility would be to extend > logbuf_cpu recursion logic to every holder of logbuf_lock. That will at > least avoid the spinlock recursion killing the machine but we won't be able > to see what lockdep found... Could tell lockdep to use trace_printk(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
