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:   Wed, 8 Sep 2021 12:09:41 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Alexey Dobriyan <adobriyan@...il.com>
Cc:     Florian Weimer <fweimer@...hat.com>,
        Linus Torvalds <torvalds@...uxfoundation.org>,
        Segher Boessenkool <segher@...nel.crashing.org>,
        Nathan Chancellor <nathan@...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

On Tue, Sep 7, 2021 at 1:02 AM Alexey Dobriyan <adobriyan@...il.com> wrote:
>
> On Mon, Sep 06, 2021 at 08:54:13AM +0200, Florian Weimer wrote:
> > * 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.
>
> What do you mean?
>
> Mainline has 1/3 and 2/3 now:
>
>         c0891ac15f0428ffa81b2e818d416bdf3cb74ab6 isystem: ship and use stdarg.h
>         39f75da7bcc829ddc4d40bb60d0e95520de7898b isystem: trim/fixup stdarg.h and other headers
>
> 3/3 is stuck in -next:
>
>         https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/log/?h=for-next
>
> I'm not sure why. If the patch is bad it should be dropped from -next
> as well. If it is good, it should be in mainline, otherwise more
> compile time failures will happen.



See

https://lore.kernel.org/all/20210906084947.4f65761d@canb.auug.org.au/

Your 3/3 correctly detected a new use of <stddef.h>
in the drm tree.

Stephen Rothwell pointed it out a long time ago,
and fixed it in linux-next.

But, the drm maintainers did not fix it in time.
I could not fix it either since the bad commit,
b97060a99b01b4, was not in my tree.

Now it is mainlined, so my plan is to
do  s/<stddef.h>/<linux/stddef.h>/
in my tree, then include your 3/3
in my second pull request in this MW.







--
Best Regards
Masahiro Yamada