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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 9 Nov 2017 13:15:48 +0900 From: Masahiro Yamada <yamada.masahiro@...ionext.com> To: Nick Desaulniers <ndesaulniers@...gle.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 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
Powered by blists - more mailing lists