Re: [PATCH v2 00/33] locking/atomic: convert all architectures to ARCH_ATOMIC

[Arnd Bergmann]

On Wed, Jun 30, 2021 at 9:55 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> On Tue, Jun 29, 2021 at 09:36:23AM +0200, Arnd Bergmann wrote:
> > For the specific case of cmpxchg64(), I do think it would make sense to either
> > have a Kconfig symbol that controls the few users, or to provide a spinlock
> > based fallback for those that don't have a native implementation.
>
> My preference goes to a Kconfig based solution; I so detest spinlock
> based atomics. I dream of the day we can kill the lot of 'em
> (sparc32-smp, parisc-smp are always the ones that come to mind).

Fair enough.

> This is doubly true for the xchg/cmpxchg/cmpxchg64 family of functions
> that are supposed to work together with READ_ONCE/WRITE_ONCE but don't
> (when 'emulated', we'd need WRITE_ONCE to also be spinlock based in
> that case).

Ah, I had not realized that this specifically was the problem, besides
the spinlock method also being awfully slow. That means the two are
already broken beyond repair, but presumably we no longer care because
there are approximately zero remaining users, right?

> That is, at least for atomic64_*() the whole API is self contained so we
> can (and do) frob atomic64_set() to behave sanely vs atomic64_cmpxchg().

I suppose it isn't possible to completely replace cmpxchg64() and xchg64()
with their atomic64() counterparts? I see there are only a handful of users,
but presumably those are the ones that are not easily changed to atomic64_t.

         Arnd