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.. As expected this apparently fixes the problem. But are we confident enough this is the true source? If it's really that simple, printk calling into the scheduler, why am I the only one seeing this? -Arne > > --- > kernel/lockdep.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/kernel/lockdep.c b/kernel/lockdep.c > index 53a6895..e4129cf 100644 > --- a/kernel/lockdep.c > +++ b/kernel/lockdep.c > @@ -3242,7 +3242,7 @@ int lock_is_held(struct lockdep_map *lock) > int ret = 0; > > if (unlikely(current->lockdep_recursion)) > - return ret; > + return 1; /* avoid false negative lockdep_assert_held */ > > raw_local_irq_save(flags); > check_flags(flags); > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- 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