From: Sami Tolvanen <samitolvanen@google.com> To: Peter Zijlstra <peterz@infradead.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com>, Jann Horn <jannh@google.com>, "the arch/x86 maintainers" <x86@kernel.org>, Masahiro Yamada <masahiroy@kernel.org>, Steven Rostedt <rostedt@goodmis.org>, Will Deacon <will@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Paul E. McKenney" <paulmck@kernel.org>, Kees Cook <keescook@chromium.org>, Nick Desaulniers <ndesaulniers@google.com>, clang-built-linux <clang-built-linux@googlegroups.com>, Kernel Hardening <kernel-hardening@lists.openwall.com>, linux-arch <linux-arch@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, linux-kbuild <linux-kbuild@vger.kernel.org>, kernel list <linux-kernel@vger.kernel.org>, linux-pci@vger.kernel.org Subject: Re: [PATCH v6 22/25] x86/asm: annotate indirect jumps Date: Wed, 21 Oct 2020 17:22:59 -0700 [thread overview] Message-ID: <CABCJKufL6=FiaeD8T0P+mK4JeR9J80hhjvJ6Z9S-m9UnCESxVA@mail.gmail.com> (raw) In-Reply-To: <20201021085606.GZ2628@hirez.programming.kicks-ass.net> On Wed, Oct 21, 2020 at 1:56 AM Peter Zijlstra <peterz@infradead.org> wrote: > > On Tue, Oct 20, 2020 at 12:24:37PM -0700, Sami Tolvanen wrote: > > > > Building allyesconfig with this series and LTO enabled, I still see > > > > the following objtool warnings for vmlinux.o, grouped by source file: > > > > > > > > arch/x86/entry/entry_64.S: > > > > __switch_to_asm()+0x0: undefined stack state > > > > .entry.text+0xffd: sibling call from callable instruction with > > > > modified stack frame > > > > .entry.text+0x48: stack state mismatch: cfa1=7-8 cfa2=-1+0 > > > > > > Not sure what this one's about, there's no OBJECT_FILES_NON_STANDARD? > > > > Correct, because with LTO, we won't have an ELF binary to process > > until we compile everything into vmlinux.o, and at that point we can > > no longer skip individual object files. > > I think what Josh was trying to say is; this file is subject to objtool > on a normal build and does not generate warnings. So why would it > generate warnings when subject to objtool as result of a vmlinux run > (due to LTO or otherwise). > > In fact, when I build a x86_64-defconfig and then run: > > $ objtool check -barf defconfig-build/vmlinux.o Note that I'm passing also --vmlinux and --duplicate to objtool when processing vmlinux.o, and this series has a patch to split noinstr validation from --vmlinux, so that's skipped. > I do not see these in particular, although I do see a lot of: > > "sibling call from callable instruction with modified stack frame" > "falls through to next function" > > that did not show up in the individual objtool runs during the build. I'm able to reproduce these warnings with gcc 9.3 + allyesconfig, with KASAN and GCOV_KERNEL disabled, as they are not enabled in LTO builds either. This is without the LTO series applied, so we also have the retpoline warnings: $ ./tools/objtool/objtool check -arfld vmlinux.o 2>&1 | grep -vE '(sibling|instr)' vmlinux.o: warning: objtool: wakeup_long64()+0x61: indirect jump found in RETPOLINE build vmlinux.o: warning: objtool: .text+0x826308a: indirect jump found in RETPOLINE build vmlinux.o: warning: objtool: .text+0x82630c5: indirect jump found in RETPOLINE build vmlinux.o: warning: objtool: .head.text+0x748: indirect jump found in RETPOLINE build vmlinux.o: warning: objtool: set_bringup_idt_handler.constprop.0()+0x0: undefined stack state vmlinux.o: warning: objtool: .entry.text+0x1634: redundant CLD vmlinux.o: warning: objtool: camellia_cbc_dec_32way()+0xb3: stack state mismatch: cfa1=7+520 cfa2=7+8 vmlinux.o: warning: objtool: camellia_ctr_32way()+0x1a: stack state mismatch: cfa1=7+520 cfa2=7+8 vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen2()+0x12: unsupported stack pointer realignment vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen2()+0x12: unsupported stack pointer realignment vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen2()+0x12: unsupported stack pointer realignment vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen2()+0x12: unsupported stack pointer realignment vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen4()+0x12: unsupported stack pointer realignment vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen4()+0x12: unsupported stack pointer realignment vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen4()+0x12: unsupported stack pointer realignment vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen4()+0x12: unsupported stack pointer realignment vmlinux.o: warning: objtool: sha1_transform_avx2()+0xc: unsupported stack pointer realignment vmlinux.o: warning: objtool: sha1_ni_transform()+0x7: unsupported stack pointer realignment vmlinux.o: warning: objtool: sha256_transform_rorx()+0x13: unsupported stack pointer realignment vmlinux.o: warning: objtool: sha512_transform_ssse3()+0x14: unsupported stack pointer realignment vmlinux.o: warning: objtool: sha512_transform_avx()+0x14: unsupported stack pointer realignment vmlinux.o: warning: objtool: sha512_transform_rorx()+0x7: unsupported stack pointer realignment vmlinux.o: warning: objtool: __x86_retpoline_rdi()+0x10: return with modified stack frame vmlinux.o: warning: objtool: __x86_retpoline_rdi()+0x0: stack state mismatch: cfa1=7+32 cfa2=7+8 vmlinux.o: warning: objtool: __x86_retpoline_rdi()+0x0: stack state mismatch: cfa1=7+32 cfa2=-1+0 vmlinux.o: warning: objtool: reset_early_page_tables()+0x0: stack state mismatch: cfa1=7+8 cfa2=-1+0 vmlinux.o: warning: objtool: .entry.text+0x48: stack state mismatch: cfa1=7-8 cfa2=-1+0 vmlinux.o: warning: objtool: .entry.text+0x15fd: stack state mismatch: cfa1=7-8 cfa2=-1+0 vmlinux.o: warning: objtool: .entry.text+0x168c: stack state mismatch: cfa1=7-8 cfa2=-1+0 There are a couple of differences, like the first "undefined stack state" warning pointing to set_bringup_idt_handler.constprop.0() instead of __switch_to_asm(). I tried running this with --backtrace, but objtool segfaults at the first .entry.text warning: $ ./tools/objtool/objtool check -barfld vmlinux.o ... vmlinux.o: warning: objtool: set_bringup_idt_handler.constprop.0()+0x0: undefined stack state vmlinux.o: warning: objtool: xen_hypercall_set_trap_table()+0x0: <=== (sym) ... vmlinux.o: warning: objtool: .entry.text+0xffd: sibling call from callable instruction with modified stack frame vmlinux.o: warning: objtool: .entry.text+0xfcb: (branch) Segmentation fault Going back to the allyesconfig+LTO vmlinux.o, the "undefined stack state" warning looks quite similar: $ ./tools/objtool/objtool check -barlfd vmlinux.o vmlinux.o: warning: objtool: __switch_to_asm()+0x0: undefined stack state vmlinux.o: warning: objtool: xen_hypercall_set_trap_table()+0x0: <=== (sym) vmlinux.o: warning: objtool: .entry.text+0xffd: sibling call from callable instruction with modified stack frame vmlinux.o: warning: objtool: .entry.text+0xfcb: (branch) Segmentation fault Sami
WARNING: multiple messages have this Message-ID (diff)
From: Sami Tolvanen <samitolvanen@google.com> To: Peter Zijlstra <peterz@infradead.org> Cc: linux-arch <linux-arch@vger.kernel.org>, Kees Cook <keescook@chromium.org>, "Paul E. McKenney" <paulmck@kernel.org>, Jann Horn <jannh@google.com>, linux-pci@vger.kernel.org, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Masahiro Yamada <masahiroy@kernel.org>, the arch/x86 maintainers <x86@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, kernel list <linux-kernel@vger.kernel.org>, Steven Rostedt <rostedt@goodmis.org>, linux-kbuild <linux-kbuild@vger.kernel.org>, clang-built-linux <clang-built-linux@googlegroups.com>, Josh Poimboeuf <jpoimboe@redhat.com>, Kernel Hardening <kernel-hardening@lists.openwall.com>, Will Deacon <will@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v6 22/25] x86/asm: annotate indirect jumps Date: Wed, 21 Oct 2020 17:22:59 -0700 [thread overview] Message-ID: <CABCJKufL6=FiaeD8T0P+mK4JeR9J80hhjvJ6Z9S-m9UnCESxVA@mail.gmail.com> (raw) In-Reply-To: <20201021085606.GZ2628@hirez.programming.kicks-ass.net> On Wed, Oct 21, 2020 at 1:56 AM Peter Zijlstra <peterz@infradead.org> wrote: > > On Tue, Oct 20, 2020 at 12:24:37PM -0700, Sami Tolvanen wrote: > > > > Building allyesconfig with this series and LTO enabled, I still see > > > > the following objtool warnings for vmlinux.o, grouped by source file: > > > > > > > > arch/x86/entry/entry_64.S: > > > > __switch_to_asm()+0x0: undefined stack state > > > > .entry.text+0xffd: sibling call from callable instruction with > > > > modified stack frame > > > > .entry.text+0x48: stack state mismatch: cfa1=7-8 cfa2=-1+0 > > > > > > Not sure what this one's about, there's no OBJECT_FILES_NON_STANDARD? > > > > Correct, because with LTO, we won't have an ELF binary to process > > until we compile everything into vmlinux.o, and at that point we can > > no longer skip individual object files. > > I think what Josh was trying to say is; this file is subject to objtool > on a normal build and does not generate warnings. So why would it > generate warnings when subject to objtool as result of a vmlinux run > (due to LTO or otherwise). > > In fact, when I build a x86_64-defconfig and then run: > > $ objtool check -barf defconfig-build/vmlinux.o Note that I'm passing also --vmlinux and --duplicate to objtool when processing vmlinux.o, and this series has a patch to split noinstr validation from --vmlinux, so that's skipped. > I do not see these in particular, although I do see a lot of: > > "sibling call from callable instruction with modified stack frame" > "falls through to next function" > > that did not show up in the individual objtool runs during the build. I'm able to reproduce these warnings with gcc 9.3 + allyesconfig, with KASAN and GCOV_KERNEL disabled, as they are not enabled in LTO builds either. This is without the LTO series applied, so we also have the retpoline warnings: $ ./tools/objtool/objtool check -arfld vmlinux.o 2>&1 | grep -vE '(sibling|instr)' vmlinux.o: warning: objtool: wakeup_long64()+0x61: indirect jump found in RETPOLINE build vmlinux.o: warning: objtool: .text+0x826308a: indirect jump found in RETPOLINE build vmlinux.o: warning: objtool: .text+0x82630c5: indirect jump found in RETPOLINE build vmlinux.o: warning: objtool: .head.text+0x748: indirect jump found in RETPOLINE build vmlinux.o: warning: objtool: set_bringup_idt_handler.constprop.0()+0x0: undefined stack state vmlinux.o: warning: objtool: .entry.text+0x1634: redundant CLD vmlinux.o: warning: objtool: camellia_cbc_dec_32way()+0xb3: stack state mismatch: cfa1=7+520 cfa2=7+8 vmlinux.o: warning: objtool: camellia_ctr_32way()+0x1a: stack state mismatch: cfa1=7+520 cfa2=7+8 vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen2()+0x12: unsupported stack pointer realignment vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen2()+0x12: unsupported stack pointer realignment vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen2()+0x12: unsupported stack pointer realignment vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen2()+0x12: unsupported stack pointer realignment vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen4()+0x12: unsupported stack pointer realignment vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen4()+0x12: unsupported stack pointer realignment vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen4()+0x12: unsupported stack pointer realignment vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen4()+0x12: unsupported stack pointer realignment vmlinux.o: warning: objtool: sha1_transform_avx2()+0xc: unsupported stack pointer realignment vmlinux.o: warning: objtool: sha1_ni_transform()+0x7: unsupported stack pointer realignment vmlinux.o: warning: objtool: sha256_transform_rorx()+0x13: unsupported stack pointer realignment vmlinux.o: warning: objtool: sha512_transform_ssse3()+0x14: unsupported stack pointer realignment vmlinux.o: warning: objtool: sha512_transform_avx()+0x14: unsupported stack pointer realignment vmlinux.o: warning: objtool: sha512_transform_rorx()+0x7: unsupported stack pointer realignment vmlinux.o: warning: objtool: __x86_retpoline_rdi()+0x10: return with modified stack frame vmlinux.o: warning: objtool: __x86_retpoline_rdi()+0x0: stack state mismatch: cfa1=7+32 cfa2=7+8 vmlinux.o: warning: objtool: __x86_retpoline_rdi()+0x0: stack state mismatch: cfa1=7+32 cfa2=-1+0 vmlinux.o: warning: objtool: reset_early_page_tables()+0x0: stack state mismatch: cfa1=7+8 cfa2=-1+0 vmlinux.o: warning: objtool: .entry.text+0x48: stack state mismatch: cfa1=7-8 cfa2=-1+0 vmlinux.o: warning: objtool: .entry.text+0x15fd: stack state mismatch: cfa1=7-8 cfa2=-1+0 vmlinux.o: warning: objtool: .entry.text+0x168c: stack state mismatch: cfa1=7-8 cfa2=-1+0 There are a couple of differences, like the first "undefined stack state" warning pointing to set_bringup_idt_handler.constprop.0() instead of __switch_to_asm(). I tried running this with --backtrace, but objtool segfaults at the first .entry.text warning: $ ./tools/objtool/objtool check -barfld vmlinux.o ... vmlinux.o: warning: objtool: set_bringup_idt_handler.constprop.0()+0x0: undefined stack state vmlinux.o: warning: objtool: xen_hypercall_set_trap_table()+0x0: <=== (sym) ... vmlinux.o: warning: objtool: .entry.text+0xffd: sibling call from callable instruction with modified stack frame vmlinux.o: warning: objtool: .entry.text+0xfcb: (branch) Segmentation fault Going back to the allyesconfig+LTO vmlinux.o, the "undefined stack state" warning looks quite similar: $ ./tools/objtool/objtool check -barlfd vmlinux.o vmlinux.o: warning: objtool: __switch_to_asm()+0x0: undefined stack state vmlinux.o: warning: objtool: xen_hypercall_set_trap_table()+0x0: <=== (sym) vmlinux.o: warning: objtool: .entry.text+0xffd: sibling call from callable instruction with modified stack frame vmlinux.o: warning: objtool: .entry.text+0xfcb: (branch) Segmentation fault Sami _______________________________________________ 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-10-22 0:23 UTC|newest] Thread overview: 188+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-13 0:31 [PATCH v6 00/25] Add support for Clang LTO Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` [PATCH v6 01/25] kbuild: preprocess module linker script Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` [PATCH v6 02/25] objtool: Add a pass for generating __mcount_loc Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-14 16:50 ` Ingo Molnar 2020-10-14 16:50 ` Ingo Molnar 2020-10-14 18:21 ` Peter Zijlstra 2020-10-14 18:21 ` Peter Zijlstra 2020-10-15 20:10 ` Josh Poimboeuf 2020-10-15 20:10 ` Josh Poimboeuf 2020-10-13 0:31 ` [PATCH v6 03/25] objtool: Don't autodetect vmlinux.o Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` [PATCH v6 04/25] tracing: move function tracer options to Kconfig Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` [PATCH v6 05/25] tracing: add support for objtool mcount Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` [PATCH v6 06/25] x86, build: use " Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` [PATCH v6 07/25] treewide: remove DISABLE_LTO Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-14 22:43 ` Kees Cook 2020-10-14 22:43 ` Kees Cook 2020-10-17 1:46 ` Masahiro Yamada 2020-10-17 1:46 ` Masahiro Yamada 2020-10-13 0:31 ` [PATCH v6 08/25] kbuild: add support for Clang LTO Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` [PATCH v6 09/25] kbuild: lto: fix module versioning Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` [PATCH v6 10/25] objtool: Split noinstr validation from --vmlinux Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` [PATCH v6 11/25] kbuild: lto: postpone objtool Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` [PATCH v6 12/25] kbuild: lto: limit inlining Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` [PATCH v6 13/25] kbuild: lto: merge module sections Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-14 22:49 ` Kees Cook 2020-10-14 22:49 ` Kees Cook 2020-10-20 16:42 ` Sami Tolvanen 2020-10-20 16:42 ` Sami Tolvanen 2020-10-20 16:42 ` Sami Tolvanen 2020-10-13 0:31 ` [PATCH v6 14/25] kbuild: lto: remove duplicate dependencies from .mod files Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-14 22:50 ` Kees Cook 2020-10-14 22:50 ` Kees Cook 2020-12-03 17:59 ` Masahiro Yamada 2020-12-03 17:59 ` Masahiro Yamada 2020-12-03 18:47 ` Sami Tolvanen 2020-12-03 18:47 ` Sami Tolvanen 2020-12-03 18:47 ` Sami Tolvanen 2020-10-13 0:31 ` [PATCH v6 15/25] init: lto: ensure initcall ordering Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` [PATCH v6 16/25] init: lto: fix PREL32 relocations Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-14 22:53 ` Kees Cook 2020-10-14 22:53 ` Kees Cook 2020-10-15 0:12 ` Jann Horn 2020-10-15 0:12 ` Jann Horn 2020-10-15 0:12 ` Jann Horn 2020-10-13 0:31 ` [PATCH v6 17/25] PCI: Fix PREL32 relocations for LTO Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-14 22:58 ` Kees Cook 2020-10-14 22:58 ` Kees Cook 2020-10-13 0:31 ` [PATCH v6 18/25] modpost: lto: strip .lto from module names Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` [PATCH v6 19/25] scripts/mod: disable LTO for empty.c Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` [PATCH v6 20/25] efi/libstub: disable LTO Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` [PATCH v6 21/25] drivers/misc/lkdtm: disable LTO for rodata.o Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:31 ` Sami Tolvanen 2020-10-13 0:32 ` [PATCH v6 22/25] x86/asm: annotate indirect jumps Sami Tolvanen 2020-10-13 0:32 ` Sami Tolvanen 2020-10-13 0:32 ` Sami Tolvanen 2020-10-14 22:46 ` Kees Cook 2020-10-14 22:46 ` Kees Cook 2020-10-14 23:23 ` Jann Horn 2020-10-14 23:23 ` Jann Horn 2020-10-14 23:23 ` Jann Horn 2020-10-15 10:22 ` Peter Zijlstra 2020-10-15 10:22 ` Peter Zijlstra 2020-10-15 20:39 ` Josh Poimboeuf 2020-10-15 20:39 ` Josh Poimboeuf 2020-10-20 16:45 ` Sami Tolvanen 2020-10-20 16:45 ` Sami Tolvanen 2020-10-20 16:45 ` Sami Tolvanen 2020-10-20 18:52 ` Josh Poimboeuf 2020-10-20 18:52 ` Josh Poimboeuf 2020-10-20 19:24 ` Sami Tolvanen 2020-10-20 19:24 ` Sami Tolvanen 2020-10-20 19:24 ` Sami Tolvanen 2020-10-21 8:56 ` Peter Zijlstra 2020-10-21 8:56 ` Peter Zijlstra 2020-10-21 9:08 ` Peter Zijlstra 2020-10-21 9:08 ` Peter Zijlstra 2020-10-21 9:32 ` Peter Zijlstra 2020-10-21 9:32 ` Peter Zijlstra 2020-10-21 21:27 ` Josh Poimboeuf 2020-10-21 21:27 ` Josh Poimboeuf 2020-10-22 7:25 ` Peter Zijlstra 2020-10-22 7:25 ` Peter Zijlstra 2020-10-23 17:48 ` Sami Tolvanen 2020-10-23 17:48 ` Sami Tolvanen 2020-10-23 18:04 ` Nick Desaulniers 2020-10-23 18:04 ` Nick Desaulniers 2020-10-23 18:04 ` Nick Desaulniers 2020-10-21 15:01 ` Sami Tolvanen 2020-10-21 15:01 ` Sami Tolvanen 2020-10-21 15:01 ` Sami Tolvanen 2020-10-22 0:22 ` Sami Tolvanen [this message] 2020-10-22 0:22 ` Sami Tolvanen 2020-10-22 0:22 ` Sami Tolvanen 2020-10-23 17:36 ` Sami Tolvanen 2020-10-23 17:36 ` Sami Tolvanen 2020-11-09 23:11 ` Sami Tolvanen 2020-11-09 23:11 ` Sami Tolvanen 2020-11-09 23:11 ` Sami Tolvanen 2020-11-10 2:29 ` Josh Poimboeuf 2020-11-10 2:29 ` Josh Poimboeuf 2020-11-10 3:18 ` Nick Desaulniers 2020-11-10 3:18 ` Nick Desaulniers 2020-11-10 3:18 ` Nick Desaulniers 2020-11-10 4:48 ` Sami Tolvanen 2020-11-10 4:48 ` Sami Tolvanen 2020-11-10 4:48 ` Sami Tolvanen 2020-11-10 16:11 ` Josh Poimboeuf 2020-11-10 16:11 ` Josh Poimboeuf 2020-11-10 17:46 ` Josh Poimboeuf 2020-11-10 17:46 ` Josh Poimboeuf 2020-11-10 18:59 ` Sami Tolvanen 2020-11-10 18:59 ` Sami Tolvanen 2020-11-10 18:59 ` Sami Tolvanen 2020-11-13 19:54 ` Josh Poimboeuf 2020-11-13 19:54 ` Josh Poimboeuf 2020-11-13 20:24 ` Sami Tolvanen 2020-11-13 20:24 ` Sami Tolvanen 2020-11-13 20:24 ` Sami Tolvanen 2020-11-13 20:52 ` Josh Poimboeuf 2020-11-13 20:52 ` Josh Poimboeuf 2020-11-13 22:34 ` Josh Poimboeuf 2020-11-13 22:34 ` Josh Poimboeuf 2020-11-13 22:54 ` Sami Tolvanen 2020-11-13 22:54 ` Sami Tolvanen 2020-11-13 22:54 ` Sami Tolvanen 2020-11-13 22:56 ` Josh Poimboeuf 2020-11-13 22:56 ` Josh Poimboeuf 2020-11-13 23:31 ` Sami Tolvanen 2020-11-13 23:31 ` Sami Tolvanen 2020-11-13 23:31 ` Sami Tolvanen 2020-11-14 0:49 ` Josh Poimboeuf 2020-11-14 0:49 ` Josh Poimboeuf 2020-10-21 9:51 ` Peter Zijlstra 2020-10-21 9:51 ` Peter Zijlstra 2020-10-21 18:30 ` Josh Poimboeuf 2020-10-21 18:30 ` Josh Poimboeuf 2020-10-13 0:32 ` [PATCH v6 23/25] x86, vdso: disable LTO only for vDSO Sami Tolvanen 2020-10-13 0:32 ` Sami Tolvanen 2020-10-13 0:32 ` Sami Tolvanen 2020-10-13 0:32 ` [PATCH v6 24/25] x86, cpu: disable LTO for cpu.c Sami Tolvanen 2020-10-13 0:32 ` Sami Tolvanen 2020-10-13 0:32 ` Sami Tolvanen 2020-10-13 0:32 ` [PATCH v6 25/25] x86, build: allow LTO_CLANG and THINLTO to be selected Sami Tolvanen 2020-10-13 0:32 ` Sami Tolvanen 2020-10-13 0:32 ` Sami Tolvanen
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='CABCJKufL6=FiaeD8T0P+mK4JeR9J80hhjvJ6Z9S-m9UnCESxVA@mail.gmail.com' \ --to=samitolvanen@google.com \ --cc=clang-built-linux@googlegroups.com \ --cc=gregkh@linuxfoundation.org \ --cc=jannh@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=ndesaulniers@google.com \ --cc=paulmck@kernel.org \ --cc=peterz@infradead.org \ --cc=rostedt@goodmis.org \ --cc=will@kernel.org \ --cc=x86@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.