summaryrefslogtreecommitdiffstats
path: root/drivers/rpmsg
diff options
context:
space:
mode:
authorJaccon Bastiaansen <jaccon.bastiaansen@gmail.com>2013-05-13 17:28:27 +0100
committerRussell King <rmk+kernel@arm.linux.org.uk>2013-05-13 23:42:24 +0100
commit6eabb3301b1facee669d9938f7c5a0295c21d71d (patch)
tree4bd6c1782d956367ac1bf20286cfc36e10abc428 /drivers/rpmsg
parent9e01573b5cf8b3188c1f33493d2e73a30e8d25fc (diff)
downloadlinux-stable-6eabb3301b1facee669d9938f7c5a0295c21d71d.tar.gz
linux-stable-6eabb3301b1facee669d9938f7c5a0295c21d71d.tar.bz2
linux-stable-6eabb3301b1facee669d9938f7c5a0295c21d71d.zip
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/rpmsg')
0 files changed, 0 insertions, 0 deletions