diff options
author | Robert Jennings <rcj@linux.vnet.ibm.com> | 2007-01-17 10:50:20 -0600 |
---|---|---|
committer | Paul Mackerras <paulus@samba.org> | 2007-01-22 21:27:36 +1100 |
commit | 434f98c48fc1d2a1f562a28a1562a7b53e940957 (patch) | |
tree | dc722bebcbbe74282b0170955a45848b49720e16 /arch | |
parent | 06cd9396778d5b70ba27fa8158db78d6bc0f007b (diff) | |
download | kernel-crypto-434f98c48fc1d2a1f562a28a1562a7b53e940957.tar.gz kernel-crypto-434f98c48fc1d2a1f562a28a1562a7b53e940957.tar.xz kernel-crypto-434f98c48fc1d2a1f562a28a1562a7b53e940957.zip |
[POWERPC] atomic_dec_if_positive sign extension fix
On 64-bit machines, if an atomic counter is explicitly set to a
negative value, the atomic_dec_if_positive function will decrement and
store the next smallest value in the atomic counter, contrary to its
intended operation.
The comparison to determine if the decrement will make the result
negative was done by the "addic." instruction, which operates on a
64-bit value, namely the zero-extended word loaded from the atomic
variable. This patch uses an explicit word compare (cmpwi) and
changes the addic. to an addi (also changing "=&r" to "=&b" so that r0
isn't used, and addi doesn't become li).
This also fixes a bug for both 32-bit and 64-bit in that previously
0x80000000 was considered positive, since the result after
decrementing is positive. Now it is considered negative.
Also, I clarify the return value in the comments just to make it clear
that the value returned is always the decremented value, even if that
value is not stored back to the atomic counter.
Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Diffstat (limited to 'arch')
0 files changed, 0 insertions, 0 deletions