linux-kernel - Re: [GIT PULL] x86/build changes for v4.17

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:   Wed, 4 Apr 2018 11:19:09 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Matthias Kaehlcke <mka@...omium.org>,
        Ingo Molnar <mingo@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        James Y Knight <jyknight@...gle.com>,
        Chandler Carruth <chandlerc@...gle.com>,
        Stephen Hines <srhines@...gle.com>,
        Kees Cook <keescook@...gle.com>, groeck@...omium.org,
        Greg Hackmann <ghackmann@...gle.com>,
        Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [GIT PULL] x86/build changes for v4.17

On Tue, Apr 03, 2018 at 09:58:03PM +0000, Nick Desaulniers wrote:
> Speaking more with our internal LLVM teams, there ARE a few different
> approaches to implementing asm-goto in LLVM proposed, by external parties
> to Google.  These proposals haven't progressed to code review, so we've
> asked our LLVM teams to reignite these discussions with increased priority,
> if not implement the feature outright.  We (Google kernel AND llvm hackers)
> are committed to supporting the Linux kernel being built with Clang.
> 
> I can see both sides where eventually a long-requested feature-request
> should come to a head, especially with good evidence (
> https://lkml.org/lkml/2018/2/14/895), but just as you wouldn't accept a
> patch that doesn't compile with GCC, I'd like to request that we don't
> merge patches that fail to compile with Clang (or at least start to think
> what that might look like).

Again, I ask what the plans are for asm-cc-output, hard depending on
that is a few years out I imagine, but if you don't promise feature
parity for all the features we use, I can see this all happening again.

Also, it would be good to get input on the whole memory model situation;
esp. with people looking to do LTO builds, the C/C++ memory model can
cause us quite some grief, for specifics I feel we should start a new
thread. But this is another issue that's been raised several times
without feedback.