On Mon, 2011-06-06 at 11:24 +0200, Peter Zijlstra wrote: > On Mon, 2011-06-06 at 11:18 +0200, Arne Jansen wrote: > > On 06.06.2011 11:01, Peter Zijlstra wrote: > > > On Sun, 2011-06-05 at 22:15 +0200, Arne Jansen wrote: > > >> > > >> Can lockdep just get confused by the lockdep_off/on calls in printk > > >> while scheduling is allowed? There aren't many users of lockdep_off(). > > > > > > Yes!, in that case lock_is_held() returns false, triggering the warning. > > > I guess there's an argument to be made in favour of the below.. > > > > > > Two questions... is there any protection between the lockdep_recursion > > check and the set to one? I guess in our case it is, because it's the > > scheduler that calls it, but in general? > > Yeah, its always current->lockdep_recursion, so there is no > concurrency :-) > > > And why is lockdep needed to check if a lock is help? Isn't it reflected > > in the lock structure itself? > > Ah, so the difference is between _who_ owns the lock. Things like > spin_is_locked() check if the lock is taken but cannot tell you who owns > it, but lock_is_held() checks if the current context owns the lock. Also, lockdep_assert_held() doesn't generate any code when lockdep is not configured. -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|