On Sun, Jul 13, 2014 at 05:43:13PM -0400, Sasha Levin wrote: > On 07/11/2014 11:59 AM, Peter Zijlstra wrote: > >>> I agree with you that "The call trace is very clear on it that its not", but > >>> > > when you have 500 call traces you really want something better than going > >>> > > through it one call trace at a time. > >> > > >> > Points well made, and I strongly agree with Vlastimil and Sasha. > >> > There is a world of difference between a lock wanted and a lock held, > >> > and for the display of locks "held" to conceal that difference is unhelpful. > >> > It just needs one greppable word to distinguish the cases. > > So for the actual locking scenario it doesn't make a difference one way > > or another. These threads all can/could/will acquire the lock > > (eventually), so all their locking chains should be considered. > > I think that the difference here is that we're not actually debugging a locking > issue, we're merely using lockdep to help with figuring out a non-locking > related bug and finding it difficult because lockdep's list of "held locks" > is really a lie :) OK, so I suppose we could document that the top lock might not actually be held (yet). But then who will ever read said document ;-) The problem with 'fixing' this is that we don't exactly have spare storage in struct held_lock, and lock_acquired() is only enabled for CONFIG_LOCK_STAT. I just don't think its worth it.
Attachment:
pgp6633VhpszY.pgp
Description: PGP signature