On Tue, 1 Jul 2014 12:11:08 +0200 Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > On Tue, Jul 01, 2014 at 12:03:35PM +0200, Peter Zijlstra wrote: > > On Mon, Jun 30, 2014 at 11:49:40AM -0400, Jeff Layton wrote: > > > We currently have the ability to call lockdep_assert_held to throw a > > > warning when a spinlock isn't held in a codepath. There are also times > > > when we'd like to throw a warning when a lock is held (i.e. when there > > > is the potential for deadlock with atomic_dec_and_lock or similar). > > > > So I'm not getting it; if there's deadlock potential, lockdep would > > already report so, right? > > > > That is, lockdep is very good a yelling when you try to acquire a lock > > you're already holding. > > Ah, I think I see what you're trying to do. > > You're wanting to use might_lock() and might_lock_read(). Which are used > to make conditional lock acquisitions unconditional, so as to more > reliably trigger the deadlock detection. Right -- in the case of something like atomic_dec_and_lock, we only take the spinlock if we think the count might go to zero. So, we might miss catching some places that could deadlock if the refcounts don't go to zero in the testing we're doing. might_lock may be what we need, but I don't see any callers of it, and at a quick glance it doesn't appear to be disabled if debug_locks is false. -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
