linux-kernel - Re: [PATCH] Documentation/atomic_t: Document forward progress expectations

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]

Date:   Thu, 29 Jul 2021 22:03:29 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     hev <r@....cc>
Cc:     Will Deacon <will@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
        linux-kernel@...r.kernel.org, stern@...land.harvard.edu,
        parri.andrea@...il.com, npiggin@...il.com, dhowells@...hat.com,
        j.alglave@....ac.uk, luc.maranget@...ia.fr, paulmck@...nel.org,
        akiyks@...il.com, dlustig@...dia.com, joel@...lfernandes.org,
        huacai chen <chenhuacai@...il.com>,
        Guo Ren <guoren@...nel.org>, geert@...ux-m68k.org,
        Huacai Chen <chenhuacai@...ngson.cn>,
        Ingo Molnar <mingo@...hat.com>, Arnd Bergmann <arnd@...db.de>,
        wangrui <wangrui@...ngson.cn>, lixuefeng <lixuefeng@...ngson.cn>,
        Jiaxun Yang <jiaxun.yang@...goat.com>
Subject: Re: [PATCH] Documentation/atomic_t: Document forward progress
 expectations

On Fri, Jul 30, 2021 at 12:24:14AM +0800, hev wrote:
> We may need new APIs to help LL/SC to implement atomic operations, but
> this is obviously incompatible with native CAS. and many and many
> common functions are CAS friendly. Let's more functions that implement
> atomic semantics can be overridden by architecture may be a way. ;-)
> 
> In the above example, the correct implementation on LL/SC may be like:
> 
> do {
>     old = LL(&v);
>     new = func(old, &skip);
>     if (skip) {
>         break;
>     }
> } while (!SC(&v, new);
> 
> However, the success of SC may be affected by the inconstant
> complexity of func. :-(

Right, so you can't really do that because the architecture constraints
on what is allowed between LL and SC vary. Also, you couldn't compile
that code on a CAS architecture because you simply cannot implement the
LL/SC semantics using CAS.

One thing that can be done is having the compiler transform a CAS loop
into a LL/SC loop, and clang actually tries that, but GCC is absolutely
failing there:

  https://godbolt.org/z/1MK6ceq46

(note; clang only does this for arm64, and the code it does generate is
pretty horrific)

And this is another thing where C11 is utter crap; because as far as
it's concerned this is equivalent, while obviously it is not, per the
parent argument.

Also, ideally there would be a variant where you'd mandate the
forward progress or a compiler error when not possible.