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: <CAHk-=wijmmRB7-ZeT-sdxCSUoB83Lb5dnN7a7mCcH3cRw_aghQ@mail.gmail.com>
Date:   Thu, 19 Oct 2023 09:59:42 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Uros Bizjak <ubizjak@...il.com>
Cc:     peterz@...radead.org, Nadav Amit <namit@...are.com>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Brian Gerst <brgerst@...il.com>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: [PATCH v2 -tip] x86/percpu: Use C for arch_raw_cpu_ptr()

On Thu, 19 Oct 2023 at 00:04, Uros Bizjak <ubizjak@...il.com> wrote:
>
> Let me explain how the compiler handles volatile.

We're talking past each other.

You are talking about the volatile *memory* ops, and the the
difference that "raw" vs "this" would cause with and without the
"volatile".

While *I* am now convinced that the memory ops aren't even an option,
because they will generate worse code, because pretty much all users
use the "this" version (which would have to use volatile),

Because if we just stick with inline asms, the need for "volatile"
simply goes away.

The existing volatile on those percpu inline asms is *wrong*. It's a
historical mistake.

And with just a plain non-volatile inline asm, the inline asm wins.

It doesn't have the (bad) read-once behavior of a volatile memory op.

And it also doesn't have the (horrible correctness issue)
rematerialization behavior of a non-volatile memory op.

A compiler that were to rematerializes an inline asm (instead of
spilling) would be a bad joke. That's not an optimization, that's just
a crazy bad compiler with a code generation bug.

                      Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ