On Wed, 25 Sep 2019 at 22:05, Waiman Long <long...@redhat.com> wrote: > > On 9/25/19 6:01 AM, Baolin Wang wrote: > > From: Waiman Long <long...@redhat.com> > > > > [Upstream commit 513e1073d52e55b8024b4f238a48de7587c64ccf] > > > > 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(). > > > > Reported-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> > > Reported-by: syzbot+53383ae265fb161ef...@syzkaller.appspotmail.com > > Signed-off-by: Waiman Long <long...@redhat.com> > > Signed-off-by: Peter Zijlstra (Intel) <pet...@infradead.org> > > Cc: Andrew Morton <a...@linux-foundation.org> > > Cc: Linus Torvalds <torva...@linux-foundation.org> > > Cc: Paul E. McKenney <paul...@linux.vnet.ibm.com> > > Cc: Peter Zijlstra <pet...@infradead.org> > > Cc: Thomas Gleixner <t...@linutronix.de> > > Cc: Will Deacon <will.dea...@arm.com> > > Link: > > https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-long...@redhat.com > > Signed-off-by: Ingo Molnar <mi...@kernel.org> > > Signed-off-by: Baolin Wang <baolin.w...@linaro.org> > > --- > > kernel/locking/lockdep.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > > index 565005a..5c370c6 100644 > > --- a/kernel/locking/lockdep.c > > +++ b/kernel/locking/lockdep.c > > @@ -3650,6 +3650,9 @@ static int reacquire_held_locks(struct task_struct > > *curr, unsigned int depth, > > unsigned int depth; > > int i; > > > > + if (unlikely(!debug_locks)) > > + return 0; > > + > > depth = curr->lockdep_depth; > > /* > > * This function is about (re)setting the class of a held lock, > > Apparently, there are 2 such patches in the upstream kernel - commit > 513e1073d52e55b8024b4f238a48de7587c64ccf and > 71492580571467fb7177aade19c18ce7486267f5. These are probably caused by > the fact that there are 2 places in the code that can match the hunks. > Anyway, this looks like it is applying to the wrong function. It should > be applied to __lock_downgrade. Though it shouldn't harm if it is > applied to the wrong function.
Ah, I noticed there are 2 commits with the same commit message, though 513e1073d52e55b8024b4f238a48de7587c64ccf patch did not change the __lock_downgrade(), which is really confusing. This patch (513e1073d52e55b8024b4f238a48de7587c64ccf) did the right thing, and 71492580571467fb7177aade19c18ce7486267f5 patch should be applied to __lock_downgrade. I'll backport commit 71492580571467fb7177aade19c18ce7486267f5 too in future. Thanks. -- Baolin Wang Best Regards
