linux-kernel - Re: [PATCH] Restore gcc check in mips asm/unroll.h

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-=wjUEmO4GiC9mCyzZ8_WS=ZWgfg6CnpxPSLq=uoF1F3Xyw@mail.gmail.com>
Date:   Thu, 9 Jul 2020 17:53:24 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Cesar Eduardo Barros <cesarb@...arb.eti.br>,
        Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Restore gcc check in mips asm/unroll.h

On Thu, Jul 9, 2020 at 3:11 PM Cesar Eduardo Barros
<cesarb@...arb.eti.br> wrote:
>
> While raising the gcc version requirement to 4.9, the compile-time check
> in the unroll macro was accidentally changed from being used on gcc and
> clang to being used on clang only.
>
> Restore the gcc check, changing it from "gcc >= 4.7" to "all gcc".

This is clearly a thinko on my side: the old

    CONFIG_GCC_VERSION >= 40700

became pointless, so I removed, it, but it was mixed with an "||" so
we actually wanted to make it unconditional on gcc, and instead now it
checks for CLANG version even when it shouldn't.

My bad, and your patch is obviously correct.

At the same time, I do wonder if  we could just remove the check for
CLANG_VERSION >= 80000 too, and just remove all the compiler check
hackery entirely?

Older versions of clang weren't very good at compiling the Linux
kernel in the first place. Do people actually use old clang versions?
That sounds like a really bad idea.

People who used to build the kernel with clang tended to actually get
their clang version from the clang git sources afaik (I still do, but
that's because I test experimental new features that aren't released
yet), exactly because back in the bad old days there were so many
problems.

These days you can use release versions, but they'd presumably not be
older than clang-8.

Adding Nick - is it really reasonable to build any kernel with any
clang version before 8.0.0?

It turns out that the arm side also has a check for clang < 8 because
of -mcmodel=tiny, so raising the minimum required clang version to
that would solve that issue too.

Right now we don't mention minimum clang/llvm versions in our docs at
all, because we only mention gcc. Mayeb this would be good to clarify.

               Linus