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  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:   Sat, 22 Aug 2020 20:17:32 +0200
From:   Miguel Ojeda <>
To:     Sedat Dilek <>
Cc:     Segher Boessenkool <>,
        Arvind Sankar <>,
        Thomas Gleixner <>,
        Nick Desaulniers <>,
        "Paul E. McKenney" <>,
        Ingo Molnar <>, Arnd Bergmann <>,
        Borislav Petkov <>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <>,
        "H. Peter Anvin" <>,
        "Kirill A. Shutemov" <>,
        Zhenzhong Duan <>,
        Kees Cook <>,
        Peter Zijlstra <>,
        Juergen Gross <>,
        Andy Lutomirski <>,
        Andrew Cooper <>,
        LKML <>,
        clang-built-linux <>,
        Will Deacon <>,
        Linus Torvalds <>
Subject: Re: [PATCH] x86: work around clang IAS bug referencing __force_order

On Sat, Aug 22, 2020 at 11:52 AM Sedat Dilek <> wrote:
> I am asking myself who is using such ancient compilers?

There are many users/companies using older versions of compilers,
kernels and everything. GCC <= 4.9 will still be used/supported (by
third parties) for a handful of years at least.

However, the important question is whether those users/companies care
about running the latest kernels. Many of those definitely do not want
to touch their kernel either. For those that do, there are several
longterms to pick from that still support 4.9, as well as other

Thus I am usually in favor of raising the minimum whenever new hacks
are required to be added. On the other hand, we already raised the
version twice this year and it is not clear to me what is the minimum
version we would need to go for to ensure this does not bite us.

> If this is a real problem with GCC version <= 5, so can this be moved
> to a GCC specific include header-file?
> Thinking of include/linux/compiler-gcc.h or
> include/linux/compiler_types.h with a GCC-VERSION check?

That would be better if it can be done, yes.


Powered by blists - more mailing lists