The cmpxchg() function tends not to support 64-bit arguments on 32-bit
architectures. This could be either due to use of unsigned long arguments
(like on ARM) or lack of instruction support (cmpxchgq on x86). However,
these architectures may implement a specific cmpxchg64() function to
provide 64-bit cmpxchg support instead.
Since the lockref code requires a 64-bit cmpxchg and relies on the
architecture selecting ARCH_USE_CMPXCHG_LOCKREF, move to using cmpxchg64
instead of cmpxchg and allow 32-bit architectures to make use of the
lockless lockref implementation.
Cc: Waiman Long <waiman.l...@hp.com>
Signed-off-by: Will Deacon <will.dea...@arm.com>
---
An alternative to this patch is to go through the 32-bit architectures
that implement cmpxchg64, reworking their cmpxchg definitions to switch
to the 64-bit version based on the sizeof the argument.
lib/lockref.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/lockref.c b/lib/lockref.c
index e2cd2c0..677d036 100644
--- a/lib/lockref.c
+++ b/lib/lockref.c
@@ -14,8 +14,8 @@
while (likely(arch_spin_value_unlocked(old.lock.rlock.raw_lock))) {
\
struct lockref new = old, prev = old;
\
CODE
\
- old.lock_count = cmpxchg(&lockref->lock_count,
\
- old.lock_count, new.lock_count);
\
+ old.lock_count = cmpxchg64(&lockref->lock_count,
\
+ old.lock_count, new.lock_count);
\
if (likely(old.lock_count == prev.lock_count)) {
\
SUCCESS;
\
}
\
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
