summaryrefslogtreecommitdiff
path: root/drivers
diff options
context:
space:
mode:
authorJaccon Bastiaansen <jaccon.bastiaansen@gmail.com>2013-05-13 16:28:27 (GMT)
committerRussell King <rmk+kernel@arm.linux.org.uk>2013-05-13 22:42:24 (GMT)
commit6eabb3301b1facee669d9938f7c5a0295c21d71d (patch)
tree4bd6c1782d956367ac1bf20286cfc36e10abc428 /drivers
parent9e01573b5cf8b3188c1f33493d2e73a30e8d25fc (diff)
downloadlinux-6eabb3301b1facee669d9938f7c5a0295c21d71d.tar.xz
ARM: 7720/1: ARM v6/v7 cmpxchg64 shouldn't clear upper 32 bits of the old/new value
The implementation of cmpxchg64() for the ARM v6 and v7 architecture casts parameter 2 and 3 (the old and new 64bit values) to an unsigned long before calling the atomic_cmpxchg64() function. This clears the top 32 bits of the old and new values, resulting in the wrong values being compare-exchanged. Luckily, this only appears to be used for 64-bit sched_clock, which we don't (yet) have on ARM. This bug was introduced by commit 3e0f5a15f500 ("ARM: 7404/1: cmpxchg64: use atomic64 and local64 routines for cmpxchg64"). Cc: <stable@vger.kernel.org> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Jaccon Bastiaansen <jaccon.bastiaansen@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Diffstat (limited to 'drivers')
0 files changed, 0 insertions, 0 deletions