aboutsummaryrefslogtreecommitdiffstats
path: root/include/asm-powerpc/synch.h
diff options
context:
space:
mode:
authorAnton Blanchard <anton@samba.org>2006-01-13 15:37:17 +1100
committerPaul Mackerras <paulus@samba.org>2006-01-13 21:18:50 +1100
commit144b9c135b963bcb7f242c7b83bff930620d3161 (patch)
tree4b454f3e5e5921c5a528131dfa51df542259d918 /include/asm-powerpc/synch.h
parent3356bb9f7ba378a6e2709f9df95f4ea52111f4df (diff)
downloadkernel_samsung_aries-144b9c135b963bcb7f242c7b83bff930620d3161.zip
kernel_samsung_aries-144b9c135b963bcb7f242c7b83bff930620d3161.tar.gz
kernel_samsung_aries-144b9c135b963bcb7f242c7b83bff930620d3161.tar.bz2
[PATCH] powerpc: use lwsync in atomics, bitops, lock functions
eieio is only a store - store ordering. When used to order an unlock operation loads may leak out of the critical region. This is potentially buggy, one example is if a user wants to atomically read a couple of values. We can solve this with an lwsync which orders everything except store - load. I removed the (now unused) EIEIO_ON_SMP macros and the c versions isync_on_smp and eieio_on_smp now we dont use them. I also removed some old comments that were used to identify inline spinlocks in assembly, they dont make sense now our locks are out of line. Another interesting thing was that read_unlock was using an eieio even though the rest of the spinlock code had already been converted to use lwsync. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
Diffstat (limited to 'include/asm-powerpc/synch.h')
-rw-r--r--include/asm-powerpc/synch.h23
1 files changed, 4 insertions, 19 deletions
diff --git a/include/asm-powerpc/synch.h b/include/asm-powerpc/synch.h
index 794870a..c90d9d9 100644
--- a/include/asm-powerpc/synch.h
+++ b/include/asm-powerpc/synch.h
@@ -2,6 +2,8 @@
#define _ASM_POWERPC_SYNCH_H
#ifdef __KERNEL__
+#include <linux/stringify.h>
+
#ifdef __powerpc64__
#define __SUBARCH_HAS_LWSYNC
#endif
@@ -12,20 +14,12 @@
# define LWSYNC sync
#endif
-
-/*
- * Arguably the bitops and *xchg operations don't imply any memory barrier
- * or SMP ordering, but in fact a lot of drivers expect them to imply
- * both, since they do on x86 cpus.
- */
#ifdef CONFIG_SMP
-#define EIEIO_ON_SMP "eieio\n"
#define ISYNC_ON_SMP "\n\tisync"
-#define SYNC_ON_SMP __stringify(LWSYNC) "\n"
+#define LWSYNC_ON_SMP __stringify(LWSYNC) "\n"
#else
-#define EIEIO_ON_SMP
#define ISYNC_ON_SMP
-#define SYNC_ON_SMP
+#define LWSYNC_ON_SMP
#endif
static inline void eieio(void)
@@ -38,14 +32,5 @@ static inline void isync(void)
__asm__ __volatile__ ("isync" : : : "memory");
}
-#ifdef CONFIG_SMP
-#define eieio_on_smp() eieio()
-#define isync_on_smp() isync()
-#else
-#define eieio_on_smp() __asm__ __volatile__("": : :"memory")
-#define isync_on_smp() __asm__ __volatile__("": : :"memory")
-#endif
-
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_SYNCH_H */
-