linux-kernel - Re: [PATCH] kbuild: Set KBUILD_CFLAGS before incl. arch Makefile

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: <CAKwvOdny7CQMqUuaFtxishQkZZ7rWbExe7h2HNebgP4q-Myvpw@mail.gmail.com>
Date:   Thu, 9 Nov 2017 08:58:08 -0800
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Behan Webster <behanw@...verseincode.com>,
        Jan-Simon Möller <dl9pf@....de>,
        Mark Charlebois <charlebm@...il.com>,
        Greg Hackmann <ghackmann@...gle.com>,
        Matthias Kaehlcke <mka@...omium.org>,
        Chris Fries <cfries@...gle.com>,
        Michal Marek <mmarek@...e.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kbuild: Set KBUILD_CFLAGS before incl. arch Makefile

On Wed, Nov 8, 2017 at 8:15 PM, Masahiro Yamada
<yamada.masahiro@...ionext.com> wrote:
> 2017-11-08 2:37 GMT+09:00 Nick Desaulniers <ndesaulniers@...gle.com>:
>> On Sat, Nov 4, 2017 at 8:06 PM, Masahiro Yamada
>> <yamada.masahiro@...ionext.com> wrote:
>>> ld-option is only used for arch/{arm64,powerpc}/Makefile
>>>
>>> arch/arm64/Makefile:  ifeq ($(call ld-option, --fix-cortex-a53-843419),)
>>> arch/powerpc/Makefile:LDFLAGS_vmlinux += $(call
>>> ld-option,--orphan-handling=warn)
>>>
>>> I think this patch makes sense when it comes along with
>>> https://patchwork.kernel.org/patch/10030581/
>>
>> Good point.
>>
>>> but, it is now being blocked by 0-day bot
>>> due to a x86 problem.
>>
>> Looks like that is now resolved (unless 0-day bot strikes again).
>>
>>> The location of CLANG_GCC_TC define
>>> only matters after your patch is applied, right?
>>
>> By "your patch" referring to the 0-day bot thread, yes.
>>
>>> Did my request for v2 break anything?
>>
>> Nothing immediately obvious, and no regressions.  It just made this
>> patch necessary (along with my previous one) for correctly cross
>> compiling with clang for arm64 and powerpc as you point out.
>>
>>> One more thing: this patch does not apply to kbuild tree.
>>
>> I absolutely will rebase it on your tree and send a v2.  Just to help
>> me understand the contribution model better: none of my other patches
>> have yet been requested against any trees other than Linus'.  Is this
>> because of where we are in the release cycle, or that a lot of kbuild
>> code has changed, or what?
>
>
> Generally speaking,
> a preferred way is to base patches on the subsystem tree.
>
> Kernel developers are supposed to do their development on linux-next,
> but, in reality, many people work on Linus' tree since it is more stable and
> git history is fast-forward.
>
> In many cases, patches based on Linus' tree can apply to sub-systems as well.
>
> I am happy to fix-up a conflict locally
> as long as it is trivial, and there is no other reason for re-spin.
>
> Unfortunately, Kbuild tree changed the top-level Makefile a lot in
> this development cycle.
>
> If your patch does not apply cleanly, I do not know which context you
> are moving the code to.
> Also, I found suspicious description in the commit log.
>
> That's why.
>
>
> --
> Best Regards
> Masahiro Yamada

Great, thanks for taking time to explain that, I appreciate it.

-- 
Thanks,
~Nick Desaulniers