[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20040.65109.439941.444670@pilspetsen.it.uu.se>
Date: Mon, 15 Aug 2011 13:09:09 +0200
From: Mikael Pettersson <mikpe@...uu.se>
To: sparclinux@...r.kernel.org
Cc: linux-kernel@...r.kernel.org
Subject: [PATCH,SPARC] make sparc32 arch_write_unlock() match the sparc64 version
The sparc32 version of arch_write_unlock() is just a plain assignment.
Unfortunately this allows the compiler to schedule side-effects in a
protected region to occur after the HW-level unlock, which is broken.
E.g., the following trivial test case gets miscompiled:
#include <linux/spinlock.h>
rwlock_t lock;
int counter;
void foo(void) { write_lock(&lock); ++counter; write_unlock(&lock); }
Fixed by adding a compiler memory barrier to arch_write_unlock(). The
sparc64 version combines the barrier and assignment into a single asm(),
so that's what I did here as well.
Compiled-tested with a sparc32 SMP kernel.
Signed-off-by: Mikael Pettersson <mikpe@...uu.se>
---
--- linux-3.1-rc2/arch/sparc/include/asm/spinlock_32.h.~1~ 2011-07-22 12:01:08.000000000 +0200
+++ linux-3.1-rc2/arch/sparc/include/asm/spinlock_32.h 2011-08-15 11:43:49.000000000 +0200
@@ -131,6 +131,15 @@ static inline void arch_write_lock(arch_
*(volatile __u32 *)&lp->lock = ~0U;
}
+static void inline arch_write_unlock(arch_rwlock_t *lock)
+{
+ __asm__ __volatile__(
+" st %%g0, [%0]"
+ : /* no outputs */
+ : "r" (lock)
+ : "memory");
+}
+
static inline int arch_write_trylock(arch_rwlock_t *rw)
{
unsigned int val;
@@ -175,7 +184,7 @@ static inline int __arch_read_trylock(ar
res; \
})
-#define arch_write_unlock(rw) do { (rw)->lock = 0; } while(0)
+#define arch_write_unlock(rw) arch_write_unlock(rw)
#define arch_spin_lock_flags(lock, flags) arch_spin_lock(lock)
#define arch_read_lock_flags(rw, flags) arch_read_lock(rw)
--
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