From: Nick Desaulniers <ndesaulniers@google.com> To: Will Deacon <will@kernel.org>, Sami Tolvanen <samitolvanen@google.com>, Masahiro Yamada <masahiroy@kernel.org> Cc: Nathan Chancellor <natechancellor@gmail.com>, Steven Rostedt <rostedt@goodmis.org>, Josh Poimboeuf <jpoimboe@redhat.com>, Peter Zijlstra <peterz@infradead.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Paul E. McKenney" <paulmck@kernel.org>, Kees Cook <keescook@chromium.org>, clang-built-linux <clang-built-linux@googlegroups.com>, Kernel Hardening <kernel-hardening@lists.openwall.com>, linux-arch <linux-arch@vger.kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, linux-kbuild <linux-kbuild@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, PCI <linux-pci@vger.kernel.org>, Jian Cai <jiancai@google.com>, Kristof Beyls <Kristof.Beyls@arm.com> Subject: Re: [PATCH v8 00/16] Add support for Clang LTO Date: Thu, 3 Dec 2020 14:32:13 -0800 [thread overview] Message-ID: <CAKwvOdnvq=L=gQMv9MHaStmKMOuD5jvffzMedhp3gytYB6R7TQ@mail.gmail.com> (raw) In-Reply-To: <20201203182252.GA32011@willie-the-truck> On Thu, Dec 3, 2020 at 10:23 AM Will Deacon <will@kernel.org> wrote: > > On Thu, Dec 03, 2020 at 09:07:30AM -0800, Sami Tolvanen wrote: > > On Thu, Dec 3, 2020 at 3:26 AM Will Deacon <will@kernel.org> wrote: > > > I took this series for a spin, with my for-next/lto branch merged in but > > > I see a failure during the LTO stage with clang 11.0.5 because it doesn't > > > understand the '.arch_extension rcpc' directive we throw out in READ_ONCE(). > > > > I just tested this with Clang 11.0.0, which I believe is the latest > > 11.x version, and the current Clang 12 development branch, and both > > work for me. Godbolt confirms that '.arch_extension rcpc' is supported > > by the integrated assembler starting with Clang 11 (the example fails > > with 10.0.1): > > > > https://godbolt.org/z/1csGcT > > > > What does running clang --version and ld.lld --version tell you? > > I'm using some Android prebuilts I had kicking around: > > Android (6875598, based on r399163b) clang version 11.0.5 (https://android.googlesource.com/toolchain/llvm-project 87f1315dfbea7c137aa2e6d362dbb457e388158d) > Target: x86_64-unknown-linux-gnu > Thread model: posix > InstalledDir: /usr/local/google/home/willdeacon/work/android/repo/android-kernel/prebuilts-master/clang/host/linux-x86/clang-r399163b/bin > > and: > > LLD 11.0.5 (/buildbot/tmp/tmpx1DlI_ 87f1315dfbea7c137aa2e6d362dbb457e388158d) (compatible with GNU linkers) On Thu, Dec 3, 2020 at 10:22 AM Nathan Chancellor <natechancellor@gmail.com> wrote: > > 11.0.5 is AOSP's clang, which is behind the upstream 11.0.0 release so > it is most likely the case that it is missing the patch that added rcpc. > I think that a version based on the development branch (12.0.0) is in > the works but I am not sure. Yep, I have a lot of thoughts on the AOSP LLVM versioning scheme, but they're not for LKML. That's yet another reason to prefer feature detection as opposed to brittle version checks. Of course, as Will points out, if your feature detection is broken, that helps no one...more thoughts below. > > > We actually check that this extension is available before using it in > > > the arm64 Kconfig: > > > > > > config AS_HAS_LDAPR > > > def_bool $(as-instr,.arch_extension rcpc) > > > > > > so this shouldn't happen. I then realised, I wasn't passing LLVM_IAS=1 > > > on my Make command line; with that, then the detection works correctly > > > and the LTO step succeeds. > > > > > > Why is it necessary to pass LLVM_IAS=1 if LTO is enabled? I think it > > > would be _much_ better if this was implicit (or if LTO depended on it). > > > > Without LLVM_IAS=1, Clang uses two different assemblers when LTO is > > enabled: the external GNU assembler for stand-alone assembly, and > > LLVM's integrated assembler for inline assembly. as-instr tests the > > external assembler and makes an admittedly reasonable assumption that > > the test is also valid for inline assembly. > > > > I agree that it would reduce confusion in future if we just always > > enabled IAS with LTO. Nick, Nathan, any thoughts about this? > > That works for me, although I'm happy with anything which means that the > assembler checks via as-instr apply to the assembler which will ultimately > be used. I agree with Will. I think interoperability of tools is important. We should be able to mix tools from GNU and LLVM and produce working images. Specifically, combinations like gcc+llvm-nm+as+llvm-objcopy, or clang+nm+as+objcopy as two examples. There's a combinatorial explosion of combinations to test/validate, which we're not doing today, but if for some reason someone wants to use some varied combination and it doesn't work, it's worthwhile to understand the differences and issues and try to fix them. That is a win for optionality and loose coupling. That's not what's going on here though. While I think it's ok to select a compiler and assembler and linker etc from ecosystem or another, I think trying to support a build that mixes or uses different assemblers (or linkers, compilers, etc) from both for the same build is something we should draw a line in the sand and explicitly not support (except for the compat vdso's*...). ie. if I say `make LD=ld.bfd` and ld.lld gets invoked somehow (or vice versa); I consider that a bug in KBUILD. That is what's happening here, it's why as-instr feature detection is broken; because two different assemblers were used in the same build. One for inline asm, a different one for out of line asm. At the very least, it violates the Principle of Least Surprise (or is it the Law of Equivalent Exchange, I forget). In fact, lots of the work we've been doing to enable LLVM tools to build the kernel have been identifying places throughout KBUILD where tools were hardcoded rather than using what make was told to use, and we've been making progress fixing those. The ultimate test of Linux kernel build hermiticity IMO is that I should be able to build a kernel in an environment that only has one version of either GCC/binutils or LLVM, and the kernel should build without failure. That's not the case today for all arch's; cross compiling compat vdsos again are a major pain point*, but we're making progress. In that sense, the mixing of an individual GNU and LLVM utility is what I would consider a bug in KBUILD. I want to emphasize that's distinct from mixing and matching tools when invoking make, which I consider OK, if under-tested. Ok (mixes GNU and LLVM tools; gcc is the only compiler invoked, ld.lld is the only linker invoked): $ make CC=gcc LD=ld.lld Not ok (if ld.bfd or both are invoked) $ make LD=ld.lld Not ok (if ld.lld or both are invoked) $ make LD=ld.bfd Not ok (if clang's integrated assembler and GAS are invoked) $ ./scripts/config -e LTO_CLANG $ make LLVM=1 LLVM_IAS=1 The mixing of GAS and clang's integrated assembler for kernel LTO builds is a relic of a time when this series was first written when Clang's integrated assembler was in no form ready to assemble the entire Linux kernel, but could handle the inline asm for aarch64. Fortunately, ARM's LLVM team has done great work to ensure the latest extensions like RCpc are supported and compatible, and Jian has done the hard work ironing out the last mile issues in clang's assembler to get the ball in the end zone. Removing mixing GAS and clang's IA here ups the ante and removes a fallback/pressure relief valve, but I'm fine with that. Requiring clang's integrated assembler here aligns incentives to keep this working and to continue investing here. Just because it's possible to mix the use of clang's integrated assembler with GNU assembler for LTO (for some combination of versions of these tools) doesn't mean we should support it, or encourage it, for all of the reasons above. We should make this config depend on clang's integrated assembler, and not support the mixing of assemblers in one build. Thou shalt not support invoking of different tools than what's specified*. Do not pass go, do not collect $200. Full stop. * The compat vdso's are again a special case; when cross compiling using GNU tools, a separate binary with a different target triple prefix will typically get invoked than what's used to build the rest of the kernel image. This still doesn't cross the GNU/LLVM boundary though, and most importantly doesn't involve linking together object files that were built with distinct assemblers (for example). So I'd recommend to Sami to simply make the Kconfig also depend on clang's integrated assembler (not just llvm-nm and llvm-ar). If someone cares about LTO with Clang as the compiler but GAS as the assembler, then we can revisit supporting that combination (and the changes to KCONFIG), but it shouldn't be something we consider Tier 1 supported or a combination that need be supported in a minimum viable product. And at that point we should make it avoid clang's integrated assembler entirely (I suspect LTO won't work at all in that case, so maybe even considering it is a waste of time). One question I have to Will; if for aarch64 LTO will depend on RCpc, but RCpc is an ARMv8.3 extension, what are the implications for LTO on pre-ARMv8.3 aarch64 processors? -- Thanks, ~Nick Desaulniers
WARNING: multiple messages have this Message-ID (diff)
From: Nick Desaulniers <ndesaulniers@google.com> To: Will Deacon <will@kernel.org>, Sami Tolvanen <samitolvanen@google.com>, Masahiro Yamada <masahiroy@kernel.org> Cc: linux-arch <linux-arch@vger.kernel.org>, Kees Cook <keescook@chromium.org>, "Paul E. McKenney" <paulmck@kernel.org>, Kernel Hardening <kernel-hardening@lists.openwall.com>, Peter Zijlstra <peterz@infradead.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, linux-kbuild <linux-kbuild@vger.kernel.org>, PCI <linux-pci@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Steven Rostedt <rostedt@goodmis.org>, Jian Cai <jiancai@google.com>, clang-built-linux <clang-built-linux@googlegroups.com>, Josh Poimboeuf <jpoimboe@redhat.com>, Kristof Beyls <Kristof.Beyls@arm.com>, Nathan Chancellor <natechancellor@gmail.com>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v8 00/16] Add support for Clang LTO Date: Thu, 3 Dec 2020 14:32:13 -0800 [thread overview] Message-ID: <CAKwvOdnvq=L=gQMv9MHaStmKMOuD5jvffzMedhp3gytYB6R7TQ@mail.gmail.com> (raw) In-Reply-To: <20201203182252.GA32011@willie-the-truck> On Thu, Dec 3, 2020 at 10:23 AM Will Deacon <will@kernel.org> wrote: > > On Thu, Dec 03, 2020 at 09:07:30AM -0800, Sami Tolvanen wrote: > > On Thu, Dec 3, 2020 at 3:26 AM Will Deacon <will@kernel.org> wrote: > > > I took this series for a spin, with my for-next/lto branch merged in but > > > I see a failure during the LTO stage with clang 11.0.5 because it doesn't > > > understand the '.arch_extension rcpc' directive we throw out in READ_ONCE(). > > > > I just tested this with Clang 11.0.0, which I believe is the latest > > 11.x version, and the current Clang 12 development branch, and both > > work for me. Godbolt confirms that '.arch_extension rcpc' is supported > > by the integrated assembler starting with Clang 11 (the example fails > > with 10.0.1): > > > > https://godbolt.org/z/1csGcT > > > > What does running clang --version and ld.lld --version tell you? > > I'm using some Android prebuilts I had kicking around: > > Android (6875598, based on r399163b) clang version 11.0.5 (https://android.googlesource.com/toolchain/llvm-project 87f1315dfbea7c137aa2e6d362dbb457e388158d) > Target: x86_64-unknown-linux-gnu > Thread model: posix > InstalledDir: /usr/local/google/home/willdeacon/work/android/repo/android-kernel/prebuilts-master/clang/host/linux-x86/clang-r399163b/bin > > and: > > LLD 11.0.5 (/buildbot/tmp/tmpx1DlI_ 87f1315dfbea7c137aa2e6d362dbb457e388158d) (compatible with GNU linkers) On Thu, Dec 3, 2020 at 10:22 AM Nathan Chancellor <natechancellor@gmail.com> wrote: > > 11.0.5 is AOSP's clang, which is behind the upstream 11.0.0 release so > it is most likely the case that it is missing the patch that added rcpc. > I think that a version based on the development branch (12.0.0) is in > the works but I am not sure. Yep, I have a lot of thoughts on the AOSP LLVM versioning scheme, but they're not for LKML. That's yet another reason to prefer feature detection as opposed to brittle version checks. Of course, as Will points out, if your feature detection is broken, that helps no one...more thoughts below. > > > We actually check that this extension is available before using it in > > > the arm64 Kconfig: > > > > > > config AS_HAS_LDAPR > > > def_bool $(as-instr,.arch_extension rcpc) > > > > > > so this shouldn't happen. I then realised, I wasn't passing LLVM_IAS=1 > > > on my Make command line; with that, then the detection works correctly > > > and the LTO step succeeds. > > > > > > Why is it necessary to pass LLVM_IAS=1 if LTO is enabled? I think it > > > would be _much_ better if this was implicit (or if LTO depended on it). > > > > Without LLVM_IAS=1, Clang uses two different assemblers when LTO is > > enabled: the external GNU assembler for stand-alone assembly, and > > LLVM's integrated assembler for inline assembly. as-instr tests the > > external assembler and makes an admittedly reasonable assumption that > > the test is also valid for inline assembly. > > > > I agree that it would reduce confusion in future if we just always > > enabled IAS with LTO. Nick, Nathan, any thoughts about this? > > That works for me, although I'm happy with anything which means that the > assembler checks via as-instr apply to the assembler which will ultimately > be used. I agree with Will. I think interoperability of tools is important. We should be able to mix tools from GNU and LLVM and produce working images. Specifically, combinations like gcc+llvm-nm+as+llvm-objcopy, or clang+nm+as+objcopy as two examples. There's a combinatorial explosion of combinations to test/validate, which we're not doing today, but if for some reason someone wants to use some varied combination and it doesn't work, it's worthwhile to understand the differences and issues and try to fix them. That is a win for optionality and loose coupling. That's not what's going on here though. While I think it's ok to select a compiler and assembler and linker etc from ecosystem or another, I think trying to support a build that mixes or uses different assemblers (or linkers, compilers, etc) from both for the same build is something we should draw a line in the sand and explicitly not support (except for the compat vdso's*...). ie. if I say `make LD=ld.bfd` and ld.lld gets invoked somehow (or vice versa); I consider that a bug in KBUILD. That is what's happening here, it's why as-instr feature detection is broken; because two different assemblers were used in the same build. One for inline asm, a different one for out of line asm. At the very least, it violates the Principle of Least Surprise (or is it the Law of Equivalent Exchange, I forget). In fact, lots of the work we've been doing to enable LLVM tools to build the kernel have been identifying places throughout KBUILD where tools were hardcoded rather than using what make was told to use, and we've been making progress fixing those. The ultimate test of Linux kernel build hermiticity IMO is that I should be able to build a kernel in an environment that only has one version of either GCC/binutils or LLVM, and the kernel should build without failure. That's not the case today for all arch's; cross compiling compat vdsos again are a major pain point*, but we're making progress. In that sense, the mixing of an individual GNU and LLVM utility is what I would consider a bug in KBUILD. I want to emphasize that's distinct from mixing and matching tools when invoking make, which I consider OK, if under-tested. Ok (mixes GNU and LLVM tools; gcc is the only compiler invoked, ld.lld is the only linker invoked): $ make CC=gcc LD=ld.lld Not ok (if ld.bfd or both are invoked) $ make LD=ld.lld Not ok (if ld.lld or both are invoked) $ make LD=ld.bfd Not ok (if clang's integrated assembler and GAS are invoked) $ ./scripts/config -e LTO_CLANG $ make LLVM=1 LLVM_IAS=1 The mixing of GAS and clang's integrated assembler for kernel LTO builds is a relic of a time when this series was first written when Clang's integrated assembler was in no form ready to assemble the entire Linux kernel, but could handle the inline asm for aarch64. Fortunately, ARM's LLVM team has done great work to ensure the latest extensions like RCpc are supported and compatible, and Jian has done the hard work ironing out the last mile issues in clang's assembler to get the ball in the end zone. Removing mixing GAS and clang's IA here ups the ante and removes a fallback/pressure relief valve, but I'm fine with that. Requiring clang's integrated assembler here aligns incentives to keep this working and to continue investing here. Just because it's possible to mix the use of clang's integrated assembler with GNU assembler for LTO (for some combination of versions of these tools) doesn't mean we should support it, or encourage it, for all of the reasons above. We should make this config depend on clang's integrated assembler, and not support the mixing of assemblers in one build. Thou shalt not support invoking of different tools than what's specified*. Do not pass go, do not collect $200. Full stop. * The compat vdso's are again a special case; when cross compiling using GNU tools, a separate binary with a different target triple prefix will typically get invoked than what's used to build the rest of the kernel image. This still doesn't cross the GNU/LLVM boundary though, and most importantly doesn't involve linking together object files that were built with distinct assemblers (for example). So I'd recommend to Sami to simply make the Kconfig also depend on clang's integrated assembler (not just llvm-nm and llvm-ar). If someone cares about LTO with Clang as the compiler but GAS as the assembler, then we can revisit supporting that combination (and the changes to KCONFIG), but it shouldn't be something we consider Tier 1 supported or a combination that need be supported in a minimum viable product. And at that point we should make it avoid clang's integrated assembler entirely (I suspect LTO won't work at all in that case, so maybe even considering it is a waste of time). One question I have to Will; if for aarch64 LTO will depend on RCpc, but RCpc is an ARMv8.3 extension, what are the implications for LTO on pre-ARMv8.3 aarch64 processors? -- Thanks, ~Nick Desaulniers _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-12-03 22:33 UTC|newest] Thread overview: 141+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-01 21:36 [PATCH v8 00/16] Add support for Clang LTO Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-01 21:36 ` [PATCH v8 01/16] tracing: move function tracer options to Kconfig Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-01 21:47 ` Steven Rostedt 2020-12-01 21:47 ` Steven Rostedt 2020-12-01 21:36 ` [PATCH v8 02/16] kbuild: add support for Clang LTO Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-02 2:59 ` Masahiro Yamada 2020-12-02 2:59 ` Masahiro Yamada 2020-12-03 0:07 ` Nick Desaulniers 2020-12-03 0:07 ` Nick Desaulniers 2020-12-03 0:07 ` Nick Desaulniers 2020-12-01 21:36 ` [PATCH v8 03/16] kbuild: lto: fix module versioning Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-01 21:36 ` [PATCH v8 04/16] kbuild: lto: limit inlining Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-01 21:36 ` [PATCH v8 05/16] kbuild: lto: merge module sections Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-01 21:36 ` [PATCH v8 06/16] kbuild: lto: remove duplicate dependencies from .mod files Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-01 21:36 ` [PATCH v8 07/16] init: lto: ensure initcall ordering Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-01 21:36 ` [PATCH v8 08/16] init: lto: fix PREL32 relocations Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-01 21:36 ` Sami Tolvanen 2020-12-01 21:37 ` [PATCH v8 09/16] PCI: Fix PREL32 relocations for LTO Sami Tolvanen 2020-12-01 21:37 ` Sami Tolvanen 2020-12-01 21:37 ` Sami Tolvanen 2020-12-01 21:37 ` [PATCH v8 10/16] modpost: lto: strip .lto from module names Sami Tolvanen 2020-12-01 21:37 ` Sami Tolvanen 2020-12-01 21:37 ` Sami Tolvanen 2020-12-01 21:37 ` [PATCH v8 11/16] scripts/mod: disable LTO for empty.c Sami Tolvanen 2020-12-01 21:37 ` Sami Tolvanen 2020-12-01 21:37 ` Sami Tolvanen 2020-12-01 21:37 ` [PATCH v8 12/16] efi/libstub: disable LTO Sami Tolvanen 2020-12-01 21:37 ` Sami Tolvanen 2020-12-01 21:37 ` Sami Tolvanen 2020-12-01 21:37 ` [PATCH v8 13/16] drivers/misc/lkdtm: disable LTO for rodata.o Sami Tolvanen 2020-12-01 21:37 ` Sami Tolvanen 2020-12-01 21:37 ` Sami Tolvanen 2020-12-01 21:37 ` [PATCH v8 14/16] arm64: vdso: disable LTO Sami Tolvanen 2020-12-01 21:37 ` Sami Tolvanen 2020-12-01 21:37 ` Sami Tolvanen 2020-12-01 21:37 ` [PATCH v8 15/16] arm64: disable recordmcount with DYNAMIC_FTRACE_WITH_REGS Sami Tolvanen 2020-12-01 21:37 ` Sami Tolvanen 2020-12-01 21:37 ` Sami Tolvanen 2020-12-01 21:37 ` [PATCH v8 16/16] arm64: allow LTO to be selected Sami Tolvanen 2020-12-01 21:37 ` Sami Tolvanen 2020-12-01 21:37 ` Sami Tolvanen 2020-12-03 0:01 ` [PATCH v8 00/16] Add support for Clang LTO Nick Desaulniers 2020-12-03 0:01 ` Nick Desaulniers 2020-12-03 0:01 ` Nick Desaulniers 2020-12-03 11:26 ` Will Deacon 2020-12-03 11:26 ` Will Deacon 2020-12-03 17:07 ` Sami Tolvanen 2020-12-03 17:07 ` Sami Tolvanen 2020-12-03 17:07 ` Sami Tolvanen 2020-12-03 18:21 ` Nathan Chancellor 2020-12-03 18:21 ` Nathan Chancellor 2020-12-03 18:22 ` Will Deacon 2020-12-03 18:22 ` Will Deacon 2020-12-03 22:32 ` Nick Desaulniers [this message] 2020-12-03 22:32 ` Nick Desaulniers 2020-12-03 22:32 ` Nick Desaulniers 2020-12-04 9:35 ` Will Deacon 2020-12-04 9:35 ` Will Deacon 2020-12-04 22:52 ` Sami Tolvanen 2020-12-04 22:52 ` Sami Tolvanen 2020-12-04 22:52 ` Sami Tolvanen 2020-12-06 6:50 ` Nathan Chancellor 2020-12-06 6:50 ` Nathan Chancellor 2020-12-06 20:09 ` Sami Tolvanen 2020-12-06 20:09 ` Sami Tolvanen 2020-12-06 20:09 ` Sami Tolvanen 2020-12-08 0:46 ` Nathan Chancellor 2020-12-08 0:46 ` Nathan Chancellor 2020-12-08 12:15 ` Arnd Bergmann 2020-12-08 12:15 ` Arnd Bergmann 2020-12-08 12:15 ` Arnd Bergmann 2020-12-08 13:54 ` Arnd Bergmann 2020-12-08 13:54 ` Arnd Bergmann 2020-12-08 13:54 ` Arnd Bergmann 2020-12-08 16:53 ` Sami Tolvanen 2020-12-08 16:53 ` Sami Tolvanen 2020-12-08 16:53 ` Sami Tolvanen 2020-12-08 16:56 ` Arnd Bergmann 2020-12-08 16:56 ` Arnd Bergmann 2020-12-08 16:56 ` Arnd Bergmann 2020-12-08 16:43 ` Sami Tolvanen 2020-12-08 16:43 ` Sami Tolvanen 2020-12-08 16:43 ` Sami Tolvanen 2020-12-08 20:59 ` Arnd Bergmann 2020-12-08 20:59 ` Arnd Bergmann 2020-12-08 21:02 ` Arnd Bergmann 2020-12-08 21:02 ` Arnd Bergmann 2020-12-09 5:23 ` Fāng-ruì Sòng 2020-12-09 5:23 ` Fāng-ruì Sòng 2020-12-09 5:23 ` Fāng-ruì Sòng 2020-12-09 9:07 ` Arnd Bergmann 2020-12-09 9:07 ` Arnd Bergmann 2020-12-09 9:07 ` Arnd Bergmann 2020-12-09 9:59 ` Arnd Bergmann 2020-12-09 9:59 ` Arnd Bergmann 2020-12-09 16:09 ` Sami Tolvanen 2020-12-09 16:09 ` Sami Tolvanen 2020-12-09 16:09 ` Sami Tolvanen 2020-12-09 19:24 ` Arnd Bergmann 2020-12-09 19:24 ` Arnd Bergmann 2020-12-09 19:24 ` Arnd Bergmann 2020-12-08 21:09 ` Nick Desaulniers 2020-12-08 21:09 ` Nick Desaulniers 2020-12-08 21:09 ` Nick Desaulniers 2020-12-08 22:20 ` Arnd Bergmann 2020-12-08 22:20 ` Arnd Bergmann 2020-12-08 22:20 ` Arnd Bergmann 2020-12-09 16:11 ` Sami Tolvanen 2020-12-09 16:11 ` Sami Tolvanen 2020-12-09 16:11 ` Sami Tolvanen 2020-12-09 4:55 ` Fangrui Song 2020-12-09 4:55 ` Fangrui Song 2020-12-09 9:19 ` Arnd Bergmann 2020-12-09 9:19 ` Arnd Bergmann 2020-12-09 9:19 ` Arnd Bergmann 2020-12-09 12:35 ` Arnd Bergmann 2020-12-09 12:35 ` Arnd Bergmann 2020-12-09 12:35 ` Arnd Bergmann 2020-12-09 16:25 ` Sami Tolvanen 2020-12-09 16:25 ` Sami Tolvanen 2020-12-09 16:25 ` Sami Tolvanen 2020-12-09 17:51 ` Arnd Bergmann 2020-12-09 17:51 ` Arnd Bergmann 2020-12-09 17:51 ` Arnd Bergmann
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAKwvOdnvq=L=gQMv9MHaStmKMOuD5jvffzMedhp3gytYB6R7TQ@mail.gmail.com' \ --to=ndesaulniers@google.com \ --cc=Kristof.Beyls@arm.com \ --cc=clang-built-linux@googlegroups.com \ --cc=gregkh@linuxfoundation.org \ --cc=jiancai@google.com \ --cc=jpoimboe@redhat.com \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kbuild@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=masahiroy@kernel.org \ --cc=natechancellor@gmail.com \ --cc=paulmck@kernel.org \ --cc=peterz@infradead.org \ --cc=rostedt@goodmis.org \ --cc=samitolvanen@google.com \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.