Messages in this thread | | | Date | Wed, 4 Sep 2013 14:17:09 +0000 | From | Christoph Lameter <> | Subject | Re: [gcv v3 27/35] arm: Replace __get_cpu_var uses |
| |
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.
| |