diff options
author | Jaccon Bastiaansen <jaccon.bastiaansen@gmail.com> | 2013-05-13 17:28:27 +0100 |
---|---|---|
committer | Russell King <rmk+kernel@arm.linux.org.uk> | 2013-05-13 23:42:24 +0100 |
commit | 6eabb3301b1facee669d9938f7c5a0295c21d71d (patch) | |
tree | 4bd6c1782d956367ac1bf20286cfc36e10abc428 /drivers/rpmsg | |
parent | 9e01573b5cf8b3188c1f33493d2e73a30e8d25fc (diff) | |
download | linux-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