linux-kernel - Re: [GIT PULL v2] Kbuild updates for v5.15-rc1

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:   Mon, 06 Sep 2021 08:54:13 +0200
From:   Florian Weimer <fweimer@...hat.com>
To:     Alexey Dobriyan <adobriyan@...il.com>
Cc:     Linus Torvalds <torvalds@...uxfoundation.org>,
        Segher Boessenkool <segher@...nel.crashing.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        llvm@...ts.linux.dev, linux-toolchains@...r.kernel.org
Subject: Re: [GIT PULL v2] Kbuild updates for v5.15-rc1

* Linus Torvalds:

> On Sat, Sep 4, 2021 at 8:19 AM Florian Weimer <fweimer@...hat.com> wrote:
>>
>> In any case, it would be nice to know what the real motivation is.
>
> I don't know about the original motivation, but the reason I like that
> patch after-the-fact is that I've actually been in situations where I
> test out self-built compilers without installing them.

Does this really simplify matters?  Why wouldn't the gcc compiler driver
find cc1, but not be able to pass the right path options, so that the
include/ subdirectory can be located as well?

> Then it's convenient to have a completely standalone kernel tree.

The final patch in the series is here:

  isystem: delete global -isystem compile option
  <https://lore.kernel.org/linux-kernel/YQhY40teUJcTc5H4@localhost.localdomain/>

It's still not self-contained.  And it seems that there has been quite a
bit of fallout from the removal of <stddef.h>.

> Nobody cares about things like <stdatomic.h> They are completely
> irrelevant for the kernel, exactly because we've always just done our
> own, or used __builtin_xyz() for things.

Apparently, some people care enough about <stdatomic.h> to prevent its
use.  I still have not seen an explanation.  Maybe it's because we
haven't Cc:ed the patch author so far (oops).

Alexey, why are <stdatomic.h> and <float.h> so special that you called
them out in your patch?

If it's about unintended use of libatomic, then maybe we should work on
a proper compiler option that also works for __atomic builtins and the
_Atomic keyword.

Thanks,
Florian