On Mon, Jan 12, 2015 at 10:12:38AM -0500, Sasha Levin wrote: > The reason for my patch is simple:
That might have maybe been good changelog material? > I'm fuzzing with hundreds of worker threads > which at some point trigger a complete system lockup for some reason. > > When lockdep dumps the list of held locks it shows that pretty much every one > of those threads is holding the lock which caused the lockup, which is > incorrect > because it considers locks in the process of getting acquired as "held". > > This is my solution to that issue. I wanted to know which one of the threads > is > really holding the lock rather than just waiting on it. > > Is there a better way to solve that problem? Sure, think moar, if the accompanying stack trace is in the middle of the blocking primitive, ignore the top held lock ;-) Alternatively, make better/more use of lock_acquired() and track the acquire vs acquired information in the held_lock (1 bit) and look at it when printing. -- 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/
