linux-kernel - [PATCH] locking/lockdep: Fix expected depth value in __lock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 19 Oct 2015 15:30:28 -0400
From:	j.glisse@...il.com
To:	linux-kernel@...r.kernel.org
Cc:	Jérôme Glisse <jglisse@...hat.com>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Sasha Levin <sasha.levin@...cle.com>
Subject: [PATCH] locking/lockdep: Fix expected depth value in __lock_release()

From: Jérôme Glisse <jglisse@...hat.com>

In __lock_release() we are removing one entry from the stack and
rebuilding the hash chain by re-adding entry above the entry we
just removed. If the entry removed was between 2 entry of same
class then this 2 entry might be coalesced into one single entry
which in turns means that the lockdep_depth value will not be
incremented and thus the expected lockdep_depth value after this
operation will be wrong triggering an unjustified WARN_ONCE() at
the end of __lock_release().

This patch adjust the expect depth value by decrementing it if
what was previously 2 entry inside the stack are coalesced into
only one entry.

Note that __lock_set_class() does not suffer from same issue as
it adds a new class and thus can not lead to coalescing of stack
entry.

Signed-off-by: Jérôme Glisse <jglisse@...hat.com>
Cc: Ingo Molnar <mingo@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Sasha Levin <sasha.levin@...cle.com>
---
 kernel/locking/lockdep.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 4e49cc4..cac5e21 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -3428,6 +3428,8 @@ found_it:
 	curr->curr_chain_key = hlock->prev_chain_key;
 
 	for (i++; i < depth; i++) {
+		int tmp = curr->lockdep_depth;
+
 		hlock = curr->held_locks + i;
 		if (!__lock_acquire(hlock->instance,
 			hlock_class(hlock)->subclass, hlock->trylock,
@@ -3435,6 +3437,13 @@ found_it:
 				hlock->nest_lock, hlock->acquire_ip,
 				hlock->references, hlock->pin_count))
 			return 0;
+		/*
+		 * If nest_lock is true and the lock we just removed allow two
+		 * lock of same class to be consolidated in only one held_lock
+		 * then the lockdep_depth count will not increase as we expect
+		 * it to. So adjust the expected depth value accordingly.
+		 */
+		depth -= (curr->lockdep_depth == tmp);
 	}
 
 	/*
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/