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  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]
Date:	Tue, 27 Mar 2012 17:47:15 -0700
From:	Andi Kleen <>
Cc:, Andi Kleen <>
Subject: [PATCH 11/13] Add a discussion on why spin_is_locked() is bad to spinlocks.txt

From: Andi Kleen <>

Signed-off-by: Andi Kleen <>
 Documentation/spinlocks.txt |   43 +++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 43 insertions(+), 0 deletions(-)

diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt
index 9dbe885..1787229 100644
--- a/Documentation/spinlocks.txt
+++ b/Documentation/spinlocks.txt
@@ -146,6 +146,49 @@ indeed), while write-locks need to protect themselves against interrupts.
+spin_is_locked is a bad idea
+spin_is_locked checks if a lock is currently hold.  On uniprocessor kernels
+it always returns 0. In general this function should be avoided because most 
+uses of it are either redundant or broken.
+People often use spin_is_locked() to check if a particular lock is hold when a function
+is called to enforce a locking discipline, like
+	WARN_ON(!spin_is_locked(!my_lock))
+	BUG_ON(!spin_is_locked(!my_lock))
+or some variant of those.
+This does not work on uniprocessor kernels because they will always fail.
+While there are ways around that they are ugly and not recommended.
+Better use lockdep_assert_held(). This also only checks on a lock debugging
+kernel (which you should occasionally run on your code anyways because
+it catches many more problems). 
+In generally this would be better done with static annotation anyways 
+(there's some support for it in sparse)
+	BUG_ON(spin_is_locked(obj->lock));
+	kfree(obj);
+Another usage is checking whether a lock is not hold when freeing an object.
+However this is redundant because lock debugging supports this anyways
+without explicit code. Just delete the BUG_ON.
+A third usage is to check in a console function if a lock is hold, to get
+a panic crash dump out even when some other thread died in it.
+This is better implemented with spin_try_lock() and a timeout.
+Other usages are usually simply races.
+In summary just don't use it.
 Reference information:
 For dynamic initialization, use spin_lock_init() or rwlock_init() as

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists