On Thu, Jun 12, 2014 at 10:54:22AM +0200, Mike Galbraith wrote: > 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().
lkml.kernel.org/r/[email protected]
pgpLuUYbI0MSR.pgp
Description: PGP signature
