summaryrefslogtreecommitdiffstats
path: root/arch
diff options
context:
space:
mode:
authorRobert Jennings <rcj@linux.vnet.ibm.com>2007-01-17 10:50:20 -0600
committerPaul Mackerras <paulus@samba.org>2007-01-22 21:27:36 +1100
commit434f98c48fc1d2a1f562a28a1562a7b53e940957 (patch)
treedc722bebcbbe74282b0170955a45848b49720e16 /arch
parent06cd9396778d5b70ba27fa8158db78d6bc0f007b (diff)
downloadkernel-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