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-=whaqVGHSGstM4yHnJ+WkoHDBKWxMuZvgOYoxe9sYBOjEw@mail.gmail.com>
Date:   Fri, 10 Jul 2020 15:31:00 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Cesar Eduardo Barros <cesarb@...arb.eti.br>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Masahiro Yamada <masahiroy@...nel.org>
Subject: Re: [PATCH] Restore gcc check in mips asm/unroll.h

On Fri, Jul 10, 2020 at 11:43 AM Nick Desaulniers
<ndesaulniers@...gle.com> wrote:
>
> What I'd really like to see as a policy in the kernel going forward in
> that ANY new commit that adds some hack or workaround for a specific
> compiler version add a comment about which toolchain version was
> problematic, that way when we drop support for that version years
> later, we can drop whatever hacks and technical debt we've accumulated
> to support that older version.

The problem is that at the time we find and fix things, it's often
_very_ unclear which compiler versions are affected.

We also have the situation that a lot of distro compilers aren't
necessarily completely "clean" versions, particularly for the
"enterprise" ones that get stuck on some old version and then fix up
their breakage by backporting fixes.

When it's some particular version of a compiler that supports a
particular feature, that tends to be much more straightforward. But
we've had bugs where it was very unclear when exactly the bug was
fixed (fi it was fixed at all by the time we do the workaround).

              Linus