On 2019/04/25 2:08, Greg Kroah-Hartman wrote: > [ Upstream commit 71492580571467fb7177aade19c18ce7486267f5 ] > > Tetsuo Handa had reported he saw an incorrect "downgrading a read lock" > warning right after a previous lockdep warning. It is likely that the > previous warning turned off lock debugging causing the lockdep to have > inconsistency states leading to the lock downgrade warning. > > Fix that by add a check for debug_locks at the beginning of > __lock_downgrade().
Excuse me? > > Debugged-by: Tetsuo Handa <[email protected]> > Reported-by: Tetsuo Handa <[email protected]> > Reported-by: [email protected] > Signed-off-by: Waiman Long <[email protected]> > Signed-off-by: Peter Zijlstra (Intel) <[email protected]> > Cc: Andrew Morton <[email protected]> > Cc: Linus Torvalds <[email protected]> > Cc: Paul E. McKenney <[email protected]> > Cc: Peter Zijlstra <[email protected]> > Cc: Thomas Gleixner <[email protected]> > Cc: Will Deacon <[email protected]> > Link: > https://lkml.kernel.org/r/[email protected] > Signed-off-by: Ingo Molnar <[email protected]> > Signed-off-by: Sasha Levin <[email protected]> > --- > kernel/locking/lockdep.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > index fb90ca3a296e..27de98428367 100644 > --- a/kernel/locking/lockdep.c > +++ b/kernel/locking/lockdep.c > @@ -3312,6 +3312,9 @@ __lock_set_class(struct lockdep_map *lock, const char > *name, > unsigned int depth; > int i; > > + if (unlikely(!debug_locks)) > + return 0; > + This is __lock_set_class() function rather than __lock_downgrade() function. __lock_downgrade() is available in 4.12+. For 3.18-stable, downgrade_write() is in kernel/locking/rwsem.c . Therefore, we should check whether adding this check into __lock_set_class() is what we want to do... > depth = curr->lockdep_depth; > /* > * This function is about (re)setting the class of a held lock, >
