Re: [gcv v3 27/35] arm: Replace __get_cpu_var uses

[Christoph Lameter]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/