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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0804010236110.5541@jikos.suse.cz>
Date:	Tue, 1 Apr 2008 02:40:37 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Ingo Molnar <mingo@...e.hu>
cc:	linux-kernel@...r.kernel.org
Subject: Re: spinlocks -- why are releases inlined and acquires are not?

On Tue, 1 Apr 2008, Jiri Kosina wrote:

> What is the reason for this asymetry? Shouldn't the acquiring functions 
> be implemented in the very same way? Or at least, shouldn't all the 
> __lockfunc functions be inlined?

i.e. is there any particular reason why we don't have something like the 
patch below (implemented for all the lock variants of course, this is 
just to demonstrate what I mean)?


spinlocks: inline spin_lock() in non-debug cases

inline spin_lock() in the non-debug case.

Signed-off-by: Jiri Kosina <jkosina@...e.cz>

diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index 576a5f7..30922ba 100644
--- a/include/linux/spinlock.h
+++ b/include/linux/spinlock.h
@@ -178,7 +178,12 @@ do {								\
 #define read_trylock(lock)		__cond_lock(lock, _read_trylock(lock))
 #define write_trylock(lock)		__cond_lock(lock, _write_trylock(lock))
 
+#if defined(CONFIG_DEBUG_SPINLOCK) || defined(CONFIG_PREEMPT) || \
+	!defined(CONFIG_SMP)
 #define spin_lock(lock)			_spin_lock(lock)
+#else
+#define spin_lock(lock) \
+	 do { __raw_spin_lock(&(lock)->raw_lock); __acquire(lock); } while (0)
 
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
 # define spin_lock_nested(lock, subclass) _spin_lock_nested(lock, subclass)
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ