lkml.org 
[lkml]   [2011]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [debug patch] printk: Add a printk killswitch to robustify NMI watchdog messages
From
Date
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.


\
 
 \ /
  Last update: 2011-06-06 11:55    [W:0.029 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site