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

From: Arnd Bergmann <arnd@arndb.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Randy Dunlap <rdunlap@infradead.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Will Deacon <will@kernel.org>, Boqun Feng <boqun.feng@gmail.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Brian Cain <bcain@codeaurora.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Chris Zankel <chris@zankel.net>, Rich Felker <dalias@libc.org>,
	David Miller <davem@davemloft.net>,
	Vincent Chen <deanbo422@gmail.com>, Helge Deller <deller@gmx.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Greg Ungerer <gerg@linux-m68k.org>,
	Greentime Hu <green.hu@gmail.com>, Guo Ren <guoren@kernel.org>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Max Filippov <jcmvbkbc@gmail.com>,
	Jonas Bonn <jonas@southpole.se>,
	Ley Foon Tan <ley.foon.tan@intel.com>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Matt Turner <mattst88@gmail.com>, Michal Simek <monstr@monstr.eu>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nick Hu <nickhu@andestech.com>,
	Palmer Dabbelt <palmerdabbelt@google.com>,
	Paul Mackerras <paulus@samba.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Richard Henderson <rth@twiddle.net>,
	Stafford Horne <shorne@gmail.com>,
	Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Vineet Gupta <vgupta@synopsys.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>
Subject: Re: [PATCH v2 00/33] locking/atomic: convert all architectures to ARCH_ATOMIC
Date: Wed, 30 Jun 2021 14:24:43 +0200	[thread overview]
Message-ID: <CAK8P3a0Yi7PDwBnPBRm4ZVX7FzyU_ogi+kN15zXsBg0AorFhHQ@mail.gmail.com> (raw)
In-Reply-To: <YNwji8yPUfQp/ErQ@hirez.programming.kicks-ass.net>

On Wed, Jun 30, 2021 at 9:55 AM Peter Zijlstra <peterz@infradead.org> 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