Michael Schnell wrote: > Jamie Lokier wrote: > > Look in arch/arm/kernel/entry-armv.S for __kernel_cmpxchg, > > kuser_cmpxchg_fixup, and all the places where kuser_cmpxchg_fixup is > > called in that file. > > > > Here they say: > /* > * The only thing that can break atomicity in this cmpxchg > * implementation is either an IRQ or a data abort exception > * causing another process/thread to be scheduled in the middle > * of the critical sequence. To prevent this, code is added to > * the IRQ and data abort exception handlers to set the pc back > * to the beginning of the critical section if it is found to be > * within that critical section (see kuser_cmpxchg_fixup). > */ > > So the "trick" involves modifying the basic interrupt handler code. > This of course is a *nasty* trick.
Only the common entry or exit path. Nasty perhaps (I like it), but fast - good for thread primitives. It's a moderately common trick in tight code on microcontrollers, to move a check out of some critical fast path (especially copying and I/O loops) into the rarely executed interrupt handlers. It's also done in userspace, e.g. by signal handlers in some Java runtimes, again to move checks away from frequently executed fast paths in regular code. It's worthy of a Pattern name but I don't know if there is one (or an Anti-pattern if you prefer ;-) If you don't like that, you might not like other dirty tricks in the interrupt path like TIF_NEED_RESCHED and TIF_RESTORE_SIGMASK... but they do the job. :-) > I'll take a look if this is viable for the NIOS architecture. On noMMU, an alternative to using a vsyscall page is to put the cmpxchg routine in userspace (in Glibc/uclibc), and tell the kernel what addresses to check for, with a dedicated system call (just like set_thread_area has a dedicated system call). The kernel will store the address in per-task state. That will save a memory load on noMMU when calling the routine because it'll be a direct call instead of indirect. -- Jamie _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
