| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20150112153747.GE25256@twins.programming.kicks-ass.net> Date: Mon, 12 Jan 2015 16:37:47 +0100 From: Peter Zijlstra <peterz@...radead.org> To: Sasha Levin <sasha.levin@...cle.com> Cc: linux-kernel@...r.kernel.org, mingo@...hat.com Subject: Re: [RFC 1/4] lockdep: additional lock specific information when dumping locks 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 majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists