aboutsummaryrefslogtreecommitdiff
path: root/arch/s390/include/asm/cmpxchg.h
AgeCommit message (Collapse)Author
2012-09-26s390/cmpxchg,percpu: implement cmpxchg_double()Heiko Carstens
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2012-05-30s390/cmpxchg: fix sign extension bugsHeiko Carstens
For 1 and 2 byte operands for xchg and cmpxchg the old and new values get or'ed into the larger 4 byte old value before the compare and swap instruction gets executed. This is done without using the proper byte mask before or'ing the values. If the caller passed in negative old or new values these got sign extended by the caller. Which in turn means that either the old value never matches, or, even worse, unrelated bytes would be changed in memory. Luckily there don't seem to be any callers around yet, since that would have resulted in the specification exception fixed in an earlies patch. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2012-05-30s390/cmpxchg: fix 1 and 2 byte memory accessesHeiko Carstens
When accessing a 1 or 2 byte memory operand we cannot use the passed address since the compare and swap instruction only works for 4 byte aligned memory operands. Hence we calculate an aligned address so that compare and swap works correctly. However we don't pass the calculated address to the inline assembly. This results in incorrect memory accesses and in a specification exception if used on non 4 byte aligned memory operands. Since this didn't happen until now, there don't seem to be too many users of cmpxchg on unaligned addresses. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2012-05-30s390/cmpxchg: fix compile warnings specific to s390Heiko Carstens
The cmpxchg macros and functions are a bit different than on other architectures. In particular the macros do not store the return value of a __cmpxchg function call in a variable before returning the value. This causes compile warnings that only occur on s390 like this one: net/ipv4/af_inet.c: In function 'build_ehash_secret': net/ipv4/af_inet.c:241:2: warning: value computed is not used [-Wunused-value] To get rid of these warnings use the same construct that we already use for the xchg macro, which was introduced for the same reason. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2012-05-30s390/cmpxchg: add missing memory barrier to cmpxchg64Heiko Carstens
All cmpxchg functions imply a memory barrier. cmpxch64 did not have one for 31 bit code, so add it. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2011-05-23[S390] percpu: implement arch specific irqsafe_cpu_opsHeiko Carstens
Implement arch specific irqsafe_cpu ops. The arch specific ops do not disable/enable interrupts since that is an expensive operation. Instead we disable preemption and perform a compare and swap loop. Since on server distros (the ones we care about) preemption is disabled the preempt_disable()/preempt_enable() pair is a nop. In the end this code should be faster than the generic one. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2011-03-23[S390] cmpxchg: implement cmpxchg64()Heiko Carstens
We have a cmpxchg64_local() implementation but strange enough the SMP capable variant cmpxchg64() is missing. So implement it. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2011-03-23[S390] xchg/cmpxchg: move to own header fileHeiko Carstens
Move xchg() and cmpxchg() functions to own header file like some other architectures have done. With this we make sure that system.h now really looks like a place where everything is gathered that doesn't fit anywhere else. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>