linux-kernel - Re: [PATCH v2 00/33] locking/atomic: convert all architectures to ARCH

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAK8P3a0Yi7PDwBnPBRm4ZVX7FzyU_ogi+kN15zXsBg0AorFhHQ@mail.gmail.com>
Date:   Wed, 30 Jun 2021 14:24:43 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Randy Dunlap <rdunlap@...radead.org>,
        Mark Rutland <mark.rutland@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Will Deacon <will@...nel.org>,
        Boqun Feng <boqun.feng@...il.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Brian Cain <bcain@...eaurora.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Chris Zankel <chris@...kel.net>, Rich Felker <dalias@...c.org>,
        David Miller <davem@...emloft.net>,
        Vincent Chen <deanbo422@...il.com>,
        Helge Deller <deller@....de>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Greg Ungerer <gerg@...ux-m68k.org>,
        Greentime Hu <green.hu@...il.com>, Guo Ren <guoren@...nel.org>,
        Ivan Kokshaysky <ink@...assic.park.msu.ru>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        Max Filippov <jcmvbkbc@...il.com>,
        Jonas Bonn <jonas@...thpole.se>,
        Ley Foon Tan <ley.foon.tan@...el.com>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Matt Turner <mattst88@...il.com>,
        Michal Simek <monstr@...str.eu>,
        Michael Ellerman <mpe@...erman.id.au>,
        Nick Hu <nickhu@...estech.com>,
        Palmer Dabbelt <palmerdabbelt@...gle.com>,
        Paul Mackerras <paulus@...ba.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Richard Henderson <rth@...ddle.net>,
        Stafford Horne <shorne@...il.com>,
        Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Vineet Gupta <vgupta@...opsys.com>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>
Subject: Re: [PATCH v2 00/33] locking/atomic: convert all architectures to ARCH_ATOMIC

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