>
> ---
> Subject: lockdep: fix mismatched lockdep_depth/curr_chain_hash
> From: Gregory Haskins <ghaskins@novell.com>
>
> It is possible for the current->curr_chain_key to become inconsistent with the
> current index if the chain fails to validate. The end result is that future
> lock_acquire() operations may inadvertently fail to find a hit in the cache
> resulting in a new node being added to the graph for every acquire.
>
> [ peterz: this might explain some of the lockdep is so _slow_ complaints. ]
> [ mingo: this does not impact the correctness of validation, but may slow
> down future operations significantly, if the chain gets very long. ]
>
> Signed-off-by: Gregory Haskins <ghaskins@novell.com>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
> kernel/lockdep.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6/kernel/lockdep.c
> ===================================================================
> --- linux-2.6.orig/kernel/lockdep.c
> +++ linux-2.6/kernel/lockdep.c
> @@ -2166,7 +2166,6 @@ out_calc_hash:
> }
> #endif
> chain_key = iterate_chain_key(chain_key, id);
> - curr->curr_chain_key = chain_key;
>
> /*
> * Trylock needs to maintain the stack of held locks, but it
> @@ -2215,6 +2214,7 @@ out_calc_hash:
> if (unlikely(!debug_locks))
> return 0;
>
> + curr->curr_chain_key = chain_key;
> curr->lockdep_depth++;
> check_chain_key(curr);
> #ifdef CONFIG_DEBUG_LOCKDEP
>
>
> _______________________________________________
> stable mailing list
>
stable@linux.kernel.org
>
http://linux.kernel.org/mailman/listinfo/stable
