On Thu, 25 Jul 2019, Nick Desaulniers wrote: I'm really impressed how you manage to make the cover letter (0/N) a reply to 1/N instead of 1..N/N being a reply to 0/N.
In-Reply-To: <[email protected]> Message-Id: <[email protected]> Is that a new git feature to be $corp top-posting compliant? > 1. Reuse the implementation of memcpy and memset instead of relying on > __builtin_memcpy and __builtin_memset as it causes infinite recursion > in Clang (at any opt level) or GCC at -O2. > 2. Don't reset KBUILD_CFLAGS, rather filter CONFIG_FUNCTION_TRACER, > CONFIG_STACKPROTECTOR, and CONFIG_STACKPROTECTOR_STRONG flags via > `CFLAGS_REMOVE_<file>.o' > > A good test of this series (besides boot testing a kexec kernel): > * There should be no undefined symbols in arch/x86/purgatory/purgatory.ro: > $ nm arch/x86/purgatory/purgatory.ro > particularly `warn`, `bcmp`, `__stack_chk_fail`, `memcpy` or `memset`. > * `-pg`, `-fstack-protector`, `-fstack-protector-strong` should not be > added to the command line for the c source files under arch/x86/purgatory/ > when compiling with CONFIG_FUNCTION_TRACER=y, CONFIG_STACKPROTECTOR=y, > and CONFIG_STACKPROTECTOR_STRONG=y. > > V4 of: https://lkml.org/lkml/2019/7/23/864 Please don't use lkml.org references. I know it's popular but equally unreliable at times. The long term reliable reference is message id based, i.e.: lkml.kernel.org/r/$MSGID or lore.kernel.org/lkml/$MSGID even if the base URLs would cease to exist, the message id will give you a trivial way to find the relevant thread, but if '2019/7/23/864' stops to work, good luck in finding the original post. I wasted hours on that just because a subject line changed enough to confuse the big internet stalking machines. Thanks, tglx
