From: Waiman Long <[email protected]>
[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 <[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: Baolin Wang <[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 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,
--
1.7.9.5
On Thu, Sep 05, 2019 at 11:07:14AM +0800, Baolin Wang wrote:
> From: Waiman Long <[email protected]>
>
> [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 <[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: Baolin Wang <[email protected]>
> ---
> kernel/locking/lockdep.c | 3 +++
> 1 file changed, 3 insertions(+)
Why isn't this relevant for 4.19.y? I can't add a patch to 4.14.y and
then have someone upgrade to 4.19.y and not have the same fix in there,
that would be a regression.
So can you redo this series also with a 4.19.y set at the same so we
don't get out of sync? I've queued up your first patch already as that
was in 4.19.y (and also needed in 4.9.y).
thanks,
greg k-h
On Tue, 10 Sep 2019 at 22:32, Greg KH <[email protected]> wrote:
>
> On Thu, Sep 05, 2019 at 11:07:14AM +0800, Baolin Wang wrote:
> > From: Waiman Long <[email protected]>
> >
> > [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 <[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: Baolin Wang <[email protected]>
> > ---
> > kernel/locking/lockdep.c | 3 +++
> > 1 file changed, 3 insertions(+)
>
> Why isn't this relevant for 4.19.y? I can't add a patch to 4.14.y and
> then have someone upgrade to 4.19.y and not have the same fix in there,
> that would be a regression.
>
> So can you redo this series also with a 4.19.y set at the same so we
> don't get out of sync? I've queued up your first patch already as that
> was in 4.19.y (and also needed in 4.9.y).
I understood, will do. Thanks.
--
Baolin Wang
Best Regards