Hello Steven, Thanks for your explanation, here are my answers: > > So, A normal (non-raw) spinlock should NOT be used here, because that > > does would be converted to a rt-mutex, which is preemptible. If this > > code is preemptible, it could be preempted by another user space > > thread which could, in theory, modify the same piece of memory, and > > thus causing a race condition. > > Are you talking about this code? Yes! > > + spin_lock(&futex_atomic_lock); > + > + __asm__ __volatile__( "@futex_atomic_cmpxchg_inatomic \n" > + "1: ldrt %0, [%3] \n" > + " teq %0, %1 \n" > + "2: streqt %2, [%3] \n" > + "3: \n" > + " .section __ex_table, \"a\" \n" > + " .align 3 \n" > + " .long 1b, 4f, 2b, 4f \n" > + " .previous \n" > + " .section .fixup,\"ax\" \n" > + "4: mov %0, %4 \n" > + " b 3b \n" > + " .previous" > + : "=&r" (val) > + : "r" (oldval), "r" (newval), "r" (uaddr), "Ir" (-EFAULT) > + : "cc"); > + > + spin_unlock(&futex_atomic_lock); > > I don't quite remember ARM (been a few years since working with it), but > this looks like the standard "load store-conditional", or is it simply a > read/test/write? (I don't have a ARM book handy at the moment). it is a read/test/write, or in other words a cmpxchg(). > > But I would ask, what would touch that memory without first taking the > futex_atomic_lock? So I don't understand your issue of being preempted. AFAIK, it is user space memory, allocated in the context of a user space process. If this memory location is modified outside this 'protected' section, like for example in some codepath in glibc also (e.g. futex slowpath implementation), then this implementation could be dangerous with a normal spinlock/rt-mutex. > > > > Notice that there have been raised questions about the interrupt lock > > while accessing user space memory in this code, it is considered as > > not-safe. > > AFAIK the only situation where it is not-safe, is the case where the > > memory is not available in RAM, but e.g. somewhere in a swap space. If > > the memory has to be paged in, probably interrupts are needed. In my > > system things like this will never happen... > > That's nice, but other systems might have that happen ;-) And that is exactly the reason, why I have questions with this implementation... Kind Regards, Remy - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
