Messages in this thread | | | Date | Mon, 25 May 2009 17:45:33 -0400 | From | Mathieu Desnoyers <> | Subject | Re: Broken ARM (and powerpc ?) futex wrt memory barriers |
| |
* Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote: > * Russell King - ARM Linux (linux@arm.linux.org.uk) wrote: > > Hmm, the mutex is undocumented in the atomic ops document. Does it > > require ordering both before and after, or do some of those ops just > > need it before acquire and after release? > > > > I guess the mutex fast path should probably be added to atomic_ops.txt. > If I look at PowerPC mutex.h, mutex lock provides acquire semantic (like > spinlock) and mutex unlock provides release semantic (like spin unlock). > > acquire : > > take lock > smp_mb() > (critical section memory accesses) > > release : > > (critical section memory accesses) > smp_mb() > release lock
* ARM
I think we also have to deal with futexes. See arch/arm/include/asm/futex.h :
1 -
#ifdef CONFIG_SMP
#include <asm-generic/futex.h>
#else /* !SMP, we can work around lack of atomic ops by disabling preemption */
(arm-specific code here, seems to deal with futexes)
#endif
-> is it just me or this ifdef condition is the exact opposite of what it should be ? I thought those generic futexes were for UP-only systems...
Given futexes are used as key element of userspace mutex slow path implementation, I think we should consider adding memory barriers there too.
* PowerPC
Powerpc futex.h seems to have a LWSYNC_ON_SMP/ISYNC_ON_SMP before/after the futex atomic operation, which act as memory barriers.
Interestingly enough, powerpc futex.h:futex_atomic_cmpxchg_inatomic() has both LWSYNC_ON_SMP (before atomic op) and ISYNC_ON_SMP (after); this is typical for all powerpc atomic ops. However, __futex_atomic_op() only has the LWSYNC_ON_SMP. Is there a reason for not having a ISYNC_ON_SMP there ?
Mathieu
-- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
| |