linux-kernel - Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.3-4 tag

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: <87ftm8skgo.fsf@concordia.ellerman.id.au>
Date:   Sun, 11 Aug 2019 08:51:19 +1000
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     segher@...nel.crashing.org, arnd@...db.de,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nathan Chancellor <natechancellor@...il.com>,
        clang-built-linux@...glegroups.com,
        Christophe Leroy <christophe.leroy@....fr>
Subject: Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.3-4 tag

[ expanded Cc ]

Linus Torvalds <torvalds@...ux-foundation.org> writes:
> On Sat, Aug 10, 2019 at 3:11 AM Michael Ellerman <mpe@...erman.id.au> wrote:
>>
>> Just one fix, a revert of a commit that was meant to be a minor improvement to
>> some inline asm, but ended up having no real benefit with GCC and broke booting
>> 32-bit machines when using Clang.
>
> Pulled, but whenever there are possible subtle compiler issues I get
> nervous, and wonder if the problem was reported to the clang guys?

Yes, sorry I should have included more context. It was actually the
Clang Linux folks who noticed it and reported it to us:
  https://github.com/ClangBuiltLinux/linux/issues/593

There's an LLVM bug filed:
  https://bugs.llvm.org/show_bug.cgi?id=42762

And I think there's now agreement that the Clang behaviour is not
correct, Nick actually sent a revert as well but I already had one
queued:
  https://patchwork.ozlabs.org/patch/1144980/

Arnd identified some work arounds, which we may end up using, but for
this cycle we thought it was preferable to just revert this change as it
didn't actually change code generation with GCC anyway.

cheers