On Wed, 25 Sep 2019 at 22:05, Waiman Long longman@redhat.com wrote:
On 9/25/19 6:01 AM, Baolin Wang wrote:
From: Waiman Long longman@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-kernel@i-love.sakura.ne.jp Reported-by: syzbot+53383ae265fb161ef488@syzkaller.appspotmail.com Signed-off-by: Waiman Long longman@redhat.com Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Cc: Andrew Morton akpm@linux-foundation.org Cc: Linus Torvalds torvalds@linux-foundation.org Cc: Paul E. McKenney paulmck@linux.vnet.ibm.com Cc: Peter Zijlstra peterz@infradead.org Cc: Thomas Gleixner tglx@linutronix.de Cc: Will Deacon will.deacon@arm.com Link: https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-longman@redhat.c... Signed-off-by: Ingo Molnar mingo@kernel.org Signed-off-by: Baolin Wang baolin.wang@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.