summaryrefslogtreecommitdiffstats
path: root/arch/powerpc
diff options
context:
space:
mode:
authorRobert Jennings <rcj@linux.vnet.ibm.com>2007-01-17 17:50:20 +0100
committerPaul Mackerras <paulus@samba.org>2007-01-22 11:27:36 +0100
commit434f98c48fc1d2a1f562a28a1562a7b53e940957 (patch)
treedc722bebcbbe74282b0170955a45848b49720e16 /arch/powerpc
parent[POWERPC] Fix OF node refcnt underflow in 836x and 832x platform code (diff)
downloadlinux-434f98c48fc1d2a1f562a28a1562a7b53e940957.tar.xz
linux-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/powerpc')
0 files changed, 0 insertions, 0 deletions