On Wed, 4 Sep 2013, Will Deacon wrote: > > Did you apply the first patch of this series which is a bug fix? > > No, sorry, I didn't see that. Do you have a branch anywhere that I can play > with? It was merged in Linus tree yesterday. > > I do not see any special code for ARM for this_cpu_inc_return. The > > fallback solution in the core code is to disable interrupts for the > > inc_return and arch/arm/include/asm/percpu.h includes > > asm-generic/percpu.h. > > > > Where did you see it using a lock? > > God knows! You're completely right, and we simply disable interrupts which I > somehow misread as taking a lock. However, is it guaranteed that mixing > an atomic64_* access with a this_cpu_inc_return will retain atomicity > between the two? E.g. if you get interrupted during an atomic64_xchg > operation, the interrupt handler issues this_cpu_inc_return, then on return > to the xchg operation it must reissue any reads that had been executed > prior to the interrupt. This should work on ARM/ARM64 (returning from the > interrupt will clear the exclusive monitor) but I don't know about other > architectures. You cannot get interrupted during an atomic64_xchg operation. atomic and this_cpu operations are stricly serialzed since both should be behaving like single instructions. __this_cpu ops relax that requirement in case the arch code incurs significant overhead to make that happen. In cases where we know that preemption/interrupt disable etc takes care of things __this_cpu ops come into play. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
