Re: [PATCH 4.19 36/63] locking/lockdep: Add debug_locks check in __lock_downgrade()

[Tetsuo Handa]

On 2019/09/29 22:54, Greg Kroah-Hartman wrote:
> From: Waiman Long <longman@xxxxxxxxxx>
> 
> [ 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().

Please drop "[PATCH 4.19 36/63] locking/lockdep: Add debug_locks check in __lock_downgrade()".
We had a revert patch shown below in the past.

"[PATCH 4.19 37/63] locking/lockdep: Add debug_locks check in __lock_downgrade() - again" seems the correct patch.


On 2019/04/25 17:08, gregkh@xxxxxxxxxxxxxxxxxxx wrote:> 
> This is a note to let you know that I've just added the patch titled
> 
>     Revert "locking/lockdep: Add debug_locks check in __lock_downgrade()"
> 
> to the 4.19-stable tree which can be found at:
>     http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> 
> The filename of the patch is:
>      revert-locking-lockdep-add-debug_locks-check-in-__lock_downgrade.patch
> and it can be found in the queue-4.19 subdirectory.
> 
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@xxxxxxxxxxxxxxx> know about it.
> 
> 
>>From 7f437eec35a20f40d9ff82ae1c072b211c29e8e0 Mon Sep 17 00:00:00 2001
> From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> Date: Thu, 25 Apr 2019 10:00:43 +0200
> Subject: Revert "locking/lockdep: Add debug_locks check in __lock_downgrade()"
> 
> From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> 
> This reverts commit 0e0f7b30721233ce610bde2395a8e58ff7771475 which was
> commit 71492580571467fb7177aade19c18ce7486267f5 upstream.
> 
> Tetsuo rightly points out that the backport here is incorrect, as it
> touches the __lock_set_class function instead of the intended
> __lock_downgrade function.
> 
> Reported-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
> Cc: Waiman Long <longman@xxxxxxxxxx>
> Cc: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> Cc: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> Cc: Will Deacon <will.deacon@xxxxxxx>
> Cc: Ingo Molnar <mingo@xxxxxxxxxx>
> Cc: Sasha Levin <sashal@xxxxxxxxxx>
> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> ---
>  kernel/locking/lockdep.c |    3 ---
>  1 file changed, 3 deletions(-)
> 
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -3567,9 +3567,6 @@ __lock_set_class(struct lockdep_map *loc
>  	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,
> 
>