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-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170906082824.16078-4-boqun.feng@gmail.com>
Date:   Wed,  6 Sep 2017 16:28:14 +0800
From:   Boqun Feng <boqun.feng@...il.com>
To:     linux-kernel@...r.kernel.org
Cc:     Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Gautham R Shenoy <ego@...ux.vnet.ibm.com>,
        Byungchul Park <byungchul.park@....com>,
        Boqun Feng <boqun.feng@...il.com>
Subject: [RFC tip/locking v2 03/13] lockdep: Change the meanings of LOCK_{USED_IN, ENABLED}_*_{READ}

We have three types of lock acquisitions: write, non-recursive read and
recursive read, and write and non-recursive read have no difference from
a viewpoint for deadlock detections, because a write acquisition of the
corresponding lock on an independent CPU or task makes a non-recursive
lock a write lock. So we could treat them as same types in lockdep(for
example, we can call them as non-recursive locks).

As to the irq lock inversion detection(safe->unsafe deadlock detection),
we used to differ write lock with read lock(non-recursive and
recursive), such a classification could be improved as non-recursive
read lock behaves the same as write lock, so this patch changes the
meanings of LOCK_{USED_IN, ENABLED}_*_{READ}.

old:
	LOCK_* : stands for write lock
	LOCK_*_READ: stands for read lock(non-recursive and recursive)
new:
	LOCK_* : stands for non-recursive(write lock and non-recursive
	read lock)
	LOCK_*_READ: stands for recursive read lock

(The names of them should be changed too to avoid confusion, so are the
related printks, however, this patch is simply for an RFC purpose
without too many unrelated changes, in the future, I could either add
necessary changes in next versions or leave those as TODOs)

Such a change is needed for a future improvement on recursive read
related irq inversion deadlock detection.

Signed-off-by: Boqun Feng <boqun.feng@...il.com>
---
 kernel/locking/lockdep.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 5dbedcc571fd..86ef7ea9f79f 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -3091,7 +3091,7 @@ static int mark_irqflags(struct task_struct *curr, struct held_lock *hlock)
 	 * mark the lock as used in these contexts:
 	 */
 	if (!hlock->trylock) {
-		if (hlock->read) {
+		if (hlock->read == 2) {
 			if (curr->hardirq_context)
 				if (!mark_lock(curr, hlock,
 						LOCK_USED_IN_HARDIRQ_READ))
@@ -3110,7 +3110,7 @@ static int mark_irqflags(struct task_struct *curr, struct held_lock *hlock)
 		}
 	}
 	if (!hlock->hardirqs_off) {
-		if (hlock->read) {
+		if (hlock->read == 2) {
 			if (!mark_lock(curr, hlock,
 					LOCK_ENABLED_HARDIRQ_READ))
 				return 0;
-- 
2.14.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ