linux-kernel - Re: [PATCH 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a0pO=Jqbd503Kx-H_S1AzikcPjHT5=40ACZuxSF3dUFNQ@mail.gmail.com>
Date:   Mon, 10 May 2021 16:56:03 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Mark Rutland <mark.rutland@....com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Will Deacon <will@...nel.org>,
        Boqun Feng <boqun.feng@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        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>,
        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 <palmer@...belt.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 00/33] locking/atomic: convert all architectures to ARCH_ATOMIC

On Mon, May 10, 2021 at 11:39 AM Mark Rutland <mark.rutland@....com> wrote:
>
> This series (based on v5.13-rc1) converts all architectures to
> ARCH_ATOMIC. This will allow the use of instrumented atomics on all
> architectures (e.g. for KASAN and similar), and simplifies the core
> atomic code (which should allow for easier rework of the fallbacks and
> other bits in future).
>
> The series is split into three parts:
>
> 1) Some preparatory work is done to prepare architectures and common
>    code for the conversion. In this phase h8300 and microblaze are
>    converted to use the asm-generic atomics exclusively, and the
>    asm-generic implementations are made to function with or without
>    ARCH_ATOMIC.
>
> 2) Architectures are converted one-by-one to use the ARCH_ATOMIC
>    interface. I've converted each architecture with its own patch (even
>    where the conversion is trivial) to make review and bisection easier.
>
> 3) The code handling !ARCH_ATOMIC is removed.
>
> Note: I've generated the patches with:
>
>   git format-patch -C -M -D
>
> ... so the preimage of include/linux/atomic-fallback.h is not included
> in the diff when it is deleted.
>
> The series can also be found in my atomics/arch-atomic branch on
> kernel.org:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=atomics/arch-atomic
>   git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git atomics/arch-atomic

Nice work!

I had recently tried experimented with cleanups around cmpxchg(),
adding fixed-length
versions of that which can be used to implement the atomics with less bloated
preprocessor output. My patches will clearly conflict with your
series, but it seems
that we should do yours first in any case.

I'm happy to put this into the asm-generic tree once you have
collected enough Acks.

       Arnd