* [PATCH v4 1/2] x86/purgatory: do not use __builtin_memcpy and __builtin_memset
@ 2019-07-25 20:06 Nick Desaulniers
2019-07-25 20:06 ` [PATCH v4 2/2] x86/purgatory: use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS Nick Desaulniers
2019-07-25 20:06 ` [PATCH v4 0/2] Support kexec/kdump for clang built kernel Nick Desaulniers
0 siblings, 2 replies; 8+ messages in thread
From: Nick Desaulniers @ 2019-07-25 20:06 UTC (permalink / raw)
To: tglx, mingo, bp
Cc: peterz, clang-built-linux, linux-kernel, yamada.masahiro,
Nick Desaulniers, Vaibhav Rustagi, Manoj Gupta, Alistair Delva,
H. Peter Anvin, x86, Enrico Weigelt, Chao Fan, Uros Bizjak,
Alexios Zavras, Greg Kroah-Hartman, Allison Randal
Implementing memcpy and memset in terms of __builtin_memcpy and
__builtin_memset is problematic.
GCC at -O2 will replace calls to the builtins with calls to memcpy and
memset (but will generate an inline implementation at -Os). Clang will
replace the builtins with these calls regardless of optimization level.
$ llvm-objdump -dr arch/x86/purgatory/string.o | tail
0000000000000339 memcpy:
339: 48 b8 00 00 00 00 00 00 00 00 movabsq $0, %rax
000000000000033b: R_X86_64_64 memcpy
343: ff e0 jmpq *%rax
0000000000000345 memset:
345: 48 b8 00 00 00 00 00 00 00 00 movabsq $0, %rax
0000000000000347: R_X86_64_64 memset
34f: ff e0
Such code results in infinite recursion at runtime. This is observed
when doing kexec.
Instead, reuse an implementation from arch/x86/boot/compressed/string.c
if we define warn as a symbol. Also, Clang may lower memcmp's that
compare against 0 to bcmp's, so add a small definition, too. See also:
commit 5f074f3e192f ("lib/string.c: implement a basic bcmp")
Fixes: 8fc5b4d4121c ("purgatory: core purgatory functionality")
Link: https://bugs.chromium.org/p/chromium/issues/detail?id=984056
Reported-by: Vaibhav Rustagi <vaibhavrustagi@google.com>
Debugged-by: Vaibhav Rustagi <vaibhavrustagi@google.com>
Debugged-by: Manoj Gupta <manojgupta@google.com>
Suggested-by: Alistair Delva <adelva@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Vaibhav Rustagi <vaibhavrustagi@google.com>
---
Changes v3 -> v4:
* (style) open brace on newline
* drop Vaibhav's SOB tag that was accidentally copy+pasta'd from v1.
* Carry Vaibhav's tested by tag from v3 since v4 is strictly stylistic
change from v3.
* Drop cc'ing stable. Sasha's bot reports v1 doesn't cherry pick cleanly
5.1, so this series will require manual backports.
Changes v2 -> v3:
* Add bcmp implementation.
* Drop tested-by tag (Vaibhav will help retest).
* Cc stable
Changes v1 -> v2:
* Add Fixes tag.
* Move this patch to first in the series.
arch/x86/boot/string.c | 8 ++++++++
arch/x86/purgatory/Makefile | 3 +++
arch/x86/purgatory/purgatory.c | 6 ++++++
arch/x86/purgatory/string.c | 23 -----------------------
4 files changed, 17 insertions(+), 23 deletions(-)
delete mode 100644 arch/x86/purgatory/string.c
diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c
index 401e30ca0a75..8272a4492844 100644
--- a/arch/x86/boot/string.c
+++ b/arch/x86/boot/string.c
@@ -37,6 +37,14 @@ int memcmp(const void *s1, const void *s2, size_t len)
return diff;
}
+/*
+ * Clang may lower `memcmp == 0` to `bcmp == 0`.
+ */
+int bcmp(const void *s1, const void *s2, size_t len)
+{
+ return memcmp(s1, s2, len);
+}
+
int strcmp(const char *str1, const char *str2)
{
const unsigned char *s1 = (const unsigned char *)str1;
diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index 3cf302b26332..91ef244026d2 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -6,6 +6,9 @@ purgatory-y := purgatory.o stack.o setup-x86_$(BITS).o sha256.o entry64.o string
targets += $(purgatory-y)
PURGATORY_OBJS = $(addprefix $(obj)/,$(purgatory-y))
+$(obj)/string.o: $(srctree)/arch/x86/boot/compressed/string.c FORCE
+ $(call if_changed_rule,cc_o_c)
+
$(obj)/sha256.o: $(srctree)/lib/sha256.c FORCE
$(call if_changed_rule,cc_o_c)
diff --git a/arch/x86/purgatory/purgatory.c b/arch/x86/purgatory/purgatory.c
index 6d8d5a34c377..b607bda786f6 100644
--- a/arch/x86/purgatory/purgatory.c
+++ b/arch/x86/purgatory/purgatory.c
@@ -68,3 +68,9 @@ void purgatory(void)
}
copy_backup_region();
}
+
+/*
+ * Defined in order to reuse memcpy() and memset() from
+ * arch/x86/boot/compressed/string.c
+ */
+void warn(const char *msg) {}
diff --git a/arch/x86/purgatory/string.c b/arch/x86/purgatory/string.c
deleted file mode 100644
index 01ad43873ad9..000000000000
--- a/arch/x86/purgatory/string.c
+++ /dev/null
@@ -1,23 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Simple string functions.
- *
- * Copyright (C) 2014 Red Hat Inc.
- *
- * Author:
- * Vivek Goyal <vgoyal@redhat.com>
- */
-
-#include <linux/types.h>
-
-#include "../boot/string.c"
-
-void *memcpy(void *dst, const void *src, size_t len)
-{
- return __builtin_memcpy(dst, src, len);
-}
-
-void *memset(void *dst, int c, size_t len)
-{
- return __builtin_memset(dst, c, len);
-}
--
2.22.0.709.g102302147b-goog
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH v4 2/2] x86/purgatory: use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS
2019-07-25 20:06 [PATCH v4 1/2] x86/purgatory: do not use __builtin_memcpy and __builtin_memset Nick Desaulniers
@ 2019-07-25 20:06 ` Nick Desaulniers
2019-07-26 8:54 ` Thomas Gleixner
2019-07-25 20:06 ` [PATCH v4 0/2] Support kexec/kdump for clang built kernel Nick Desaulniers
1 sibling, 1 reply; 8+ messages in thread
From: Nick Desaulniers @ 2019-07-25 20:06 UTC (permalink / raw)
To: tglx, mingo, bp
Cc: peterz, clang-built-linux, linux-kernel, yamada.masahiro,
Nick Desaulniers, Vaibhav Rustagi, H. Peter Anvin, x86
KBUILD_CFLAGS is very carefully built up in the top level Makefile,
particularly when cross compiling or using different build tools.
Resetting KBUILD_CFLAGS via := assignment is an antipattern.
The comment above the reset mentions that -pg is problematic. Other
Makefiles use `CFLAGS_REMOVE_file.o = $(CC_FLAGS_FTRACE)` when
CONFIG_FUNCTION_TRACER is set. Prefer that pattern to wiping out all of
the important KBUILD_CFLAGS then manually having to re-add them. Seems
also that __stack_chk_fail references are generated when using
CONFIG_STACKPROTECTOR or CONFIG_STACKPROTECTOR_STRONG.
Fixes: 8fc5b4d4121c ("purgatory: core purgatory functionality")
Reported-by: Vaibhav Rustagi <vaibhavrustagi@google.com>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Vaibhav Rustagi <vaibhavrustagi@google.com>
---
Changes v3 -> v4:
* Use tabs to align flags (stylistic change only).
* Drop stable tag, patch 01/02 doesn't apply earlier than 5.1.
* Add tglx's suggested by tag for the tabs.
* Carry Vaibhav's tested by tag from v3 since v4 is simply stylistic.
Changes v2 -> v3:
* Prefer $(CC_FLAGS_FTRACE) which is exported to -pg.
* Also check CONFIG_STACKPROTECTOR and CONFIG_STACKPROTECTOR_STRONG.
* Cc stable.
Changes v1 -> v2:
Rather than manually add -mno-sse, -mno-mmx, -mno-sse2, prefer to filter
-pg flags.
arch/x86/purgatory/Makefile | 26 +++++++++++++++++++++-----
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index 91ef244026d2..940f043a4d97 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -20,11 +20,27 @@ KCOV_INSTRUMENT := n
# Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
# in turn leaves some undefined symbols like __fentry__ in purgatory and not
-# sure how to relocate those. Like kexec-tools, use custom flags.
-
-KBUILD_CFLAGS := -fno-strict-aliasing -Wall -Wstrict-prototypes -fno-zero-initialized-in-bss -fno-builtin -ffreestanding -c -Os -mcmodel=large
-KBUILD_CFLAGS += -m$(BITS)
-KBUILD_CFLAGS += $(call cc-option,-fno-PIE)
+# sure how to relocate those.
+ifdef CONFIG_FUNCTION_TRACER
+CFLAGS_REMOVE_sha256.o += $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_purgatory.o += $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_string.o += $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_kexec-purgatory.o += $(CC_FLAGS_FTRACE)
+endif
+
+ifdef CONFIG_STACKPROTECTOR
+CFLAGS_REMOVE_sha256.o += -fstack-protector
+CFLAGS_REMOVE_purgatory.o += -fstack-protector
+CFLAGS_REMOVE_string.o += -fstack-protector
+CFLAGS_REMOVE_kexec-purgatory.o += -fstack-protector
+endif
+
+ifdef CONFIG_STACKPROTECTOR_STRONG
+CFLAGS_REMOVE_sha256.o += -fstack-protector-strong
+CFLAGS_REMOVE_purgatory.o += -fstack-protector-strong
+CFLAGS_REMOVE_string.o += -fstack-protector-strong
+CFLAGS_REMOVE_kexec-purgatory.o += -fstack-protector-strong
+endif
$(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE
$(call if_changed,ld)
--
2.22.0.709.g102302147b-goog
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH v4 0/2] Support kexec/kdump for clang built kernel
2019-07-25 20:06 [PATCH v4 1/2] x86/purgatory: do not use __builtin_memcpy and __builtin_memset Nick Desaulniers
2019-07-25 20:06 ` [PATCH v4 2/2] x86/purgatory: use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS Nick Desaulniers
@ 2019-07-25 20:06 ` Nick Desaulniers
2019-07-25 22:51 ` Thomas Gleixner
1 sibling, 1 reply; 8+ messages in thread
From: Nick Desaulniers @ 2019-07-25 20:06 UTC (permalink / raw)
To: tglx, mingo, bp
Cc: peterz, clang-built-linux, linux-kernel, yamada.masahiro,
Nick Desaulniers
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
Nick Desaulniers (2):
x86/purgatory: do not use __builtin_memcpy and __builtin_memset
x86/purgatory: use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS
arch/x86/boot/string.c | 7 +++++++
arch/x86/purgatory/Makefile | 29 ++++++++++++++++++++++++-----
arch/x86/purgatory/purgatory.c | 6 ++++++
arch/x86/purgatory/string.c | 23 -----------------------
4 files changed, 37 insertions(+), 28 deletions(-)
delete mode 100644 arch/x86/purgatory/string.c
--
2.22.0.709.g102302147b-goog
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v4 0/2] Support kexec/kdump for clang built kernel
2019-07-25 20:06 ` [PATCH v4 0/2] Support kexec/kdump for clang built kernel Nick Desaulniers
@ 2019-07-25 22:51 ` Thomas Gleixner
2019-07-25 22:57 ` Nick Desaulniers
0 siblings, 1 reply; 8+ messages in thread
From: Thomas Gleixner @ 2019-07-25 22:51 UTC (permalink / raw)
To: Nick Desaulniers
Cc: mingo, bp, peterz, clang-built-linux, linux-kernel, yamada.masahiro
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: <20190725200625.174838-1-ndesaulniers@google.com>
Message-Id: <20190725200625.174838-3-ndesaulniers@google.com>
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v4 0/2] Support kexec/kdump for clang built kernel
2019-07-25 22:51 ` Thomas Gleixner
@ 2019-07-25 22:57 ` Nick Desaulniers
2019-07-25 23:09 ` Thomas Gleixner
0 siblings, 1 reply; 8+ messages in thread
From: Nick Desaulniers @ 2019-07-25 22:57 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Ingo Molnar, Borislav Petkov, Peter Zijlstra, clang-built-linux,
LKML, Masahiro Yamada
On Thu, Jul 25, 2019 at 3:51 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> 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: <20190725200625.174838-1-ndesaulniers@google.com>
> Message-Id: <20190725200625.174838-3-ndesaulniers@google.com>
>
> Is that a new git feature to be $corp top-posting compliant?
It appears to be a hidden bonus feature of:
$ git-send-email purgatory/v4-000*
> > 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.
Oh?
>
> 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 for the tips; I'll try to use lore.kernel.org going forward.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v4 0/2] Support kexec/kdump for clang built kernel
2019-07-25 22:57 ` Nick Desaulniers
@ 2019-07-25 23:09 ` Thomas Gleixner
0 siblings, 0 replies; 8+ messages in thread
From: Thomas Gleixner @ 2019-07-25 23:09 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Ingo Molnar, Borislav Petkov, Peter Zijlstra, clang-built-linux,
LKML, Masahiro Yamada
On Thu, 25 Jul 2019, Nick Desaulniers wrote:
> On Thu, Jul 25, 2019 at 3:51 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> > 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: <20190725200625.174838-1-ndesaulniers@google.com>
> > Message-Id: <20190725200625.174838-3-ndesaulniers@google.com>
> >
> > Is that a new git feature to be $corp top-posting compliant?
>
> It appears to be a hidden bonus feature of:
> $ git-send-email purgatory/v4-000*
Care to poke the git folks?
> > > 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.
>
> Oh?
404 or silent fail are happening on a regular base and of course always
when you really need that information. Murphy's law ...
Thanks,
tglx
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v4 2/2] x86/purgatory: use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS
2019-07-25 20:06 ` [PATCH v4 2/2] x86/purgatory: use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS Nick Desaulniers
@ 2019-07-26 8:54 ` Thomas Gleixner
2019-08-07 13:17 ` Thomas Gleixner
0 siblings, 1 reply; 8+ messages in thread
From: Thomas Gleixner @ 2019-07-26 8:54 UTC (permalink / raw)
To: Nick Desaulniers
Cc: mingo, bp, peterz, clang-built-linux, linux-kernel,
yamada.masahiro, Vaibhav Rustagi, H. Peter Anvin, x86
On Thu, 25 Jul 2019, Nick Desaulniers wrote:
> KBUILD_CFLAGS is very carefully built up in the top level Makefile,
> particularly when cross compiling or using different build tools.
> Resetting KBUILD_CFLAGS via := assignment is an antipattern.
>
> The comment above the reset mentions that -pg is problematic. Other
> Makefiles use `CFLAGS_REMOVE_file.o = $(CC_FLAGS_FTRACE)` when
> CONFIG_FUNCTION_TRACER is set. Prefer that pattern to wiping out all of
> the important KBUILD_CFLAGS then manually having to re-add them. Seems
> also that __stack_chk_fail references are generated when using
> CONFIG_STACKPROTECTOR or CONFIG_STACKPROTECTOR_STRONG.
Looking at the resulting build flags. Most stuff looks correct but there
are a few which need to be looked at twice.
removes:
-ffreestanding
-fno-builtin
-fno-zero-initialized-in-bss
changes:
-mcmodel=large to -mcmodel=kernel
adds:
-mindirect-branch-register
-mindirect-branch=thunk-extern
The latter makes me nervous. That probably wants to have retpoline disabled
as well. It's not having an instance right now, but ...
Thanks,
tglx
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v4 2/2] x86/purgatory: use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS
2019-07-26 8:54 ` Thomas Gleixner
@ 2019-08-07 13:17 ` Thomas Gleixner
0 siblings, 0 replies; 8+ messages in thread
From: Thomas Gleixner @ 2019-08-07 13:17 UTC (permalink / raw)
To: Nick Desaulniers
Cc: mingo, bp, peterz, clang-built-linux, linux-kernel,
yamada.masahiro, Vaibhav Rustagi, H. Peter Anvin, x86
On Fri, 26 Jul 2019, Thomas Gleixner wrote:
Ping...
> On Thu, 25 Jul 2019, Nick Desaulniers wrote:
>
> > KBUILD_CFLAGS is very carefully built up in the top level Makefile,
> > particularly when cross compiling or using different build tools.
> > Resetting KBUILD_CFLAGS via := assignment is an antipattern.
> >
> > The comment above the reset mentions that -pg is problematic. Other
> > Makefiles use `CFLAGS_REMOVE_file.o = $(CC_FLAGS_FTRACE)` when
> > CONFIG_FUNCTION_TRACER is set. Prefer that pattern to wiping out all of
> > the important KBUILD_CFLAGS then manually having to re-add them. Seems
> > also that __stack_chk_fail references are generated when using
> > CONFIG_STACKPROTECTOR or CONFIG_STACKPROTECTOR_STRONG.
>
> Looking at the resulting build flags. Most stuff looks correct but there
> are a few which need to be looked at twice.
>
> removes:
>
> -ffreestanding
> -fno-builtin
> -fno-zero-initialized-in-bss
>
> changes:
>
> -mcmodel=large to -mcmodel=kernel
>
> adds:
>
> -mindirect-branch-register
> -mindirect-branch=thunk-extern
>
> The latter makes me nervous. That probably wants to have retpoline disabled
> as well. It's not having an instance right now, but ...
>
> Thanks,
>
> tglx
>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-08-07 13:17 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-25 20:06 [PATCH v4 1/2] x86/purgatory: do not use __builtin_memcpy and __builtin_memset Nick Desaulniers
2019-07-25 20:06 ` [PATCH v4 2/2] x86/purgatory: use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS Nick Desaulniers
2019-07-26 8:54 ` Thomas Gleixner
2019-08-07 13:17 ` Thomas Gleixner
2019-07-25 20:06 ` [PATCH v4 0/2] Support kexec/kdump for clang built kernel Nick Desaulniers
2019-07-25 22:51 ` Thomas Gleixner
2019-07-25 22:57 ` Nick Desaulniers
2019-07-25 23:09 ` Thomas Gleixner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).