From: "Paul E. McKenney" <paulmck@kernel.org> To: Peter Zijlstra <peterz@infradead.org> Cc: Marco Elver <elver@google.com>, Nick Desaulniers <ndesaulniers@google.com>, Sami Tolvanen <samitolvanen@google.com>, Masahiro Yamada <masahiroy@kernel.org>, Will Deacon <will@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.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 <linux-arm-kernel@lists.infradead.org>, Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, linux-pci@vger.kernel.org, "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org> Subject: Re: [PATCH 00/22] add support for Clang LTO Date: Tue, 30 Jun 2020 13:30:16 -0700 [thread overview] Message-ID: <20200630203016.GI9247@paulmck-ThinkPad-P72> (raw) In-Reply-To: <20200630201243.GD4817@hirez.programming.kicks-ass.net> On Tue, Jun 30, 2020 at 10:12:43PM +0200, Peter Zijlstra wrote: > On Tue, Jun 30, 2020 at 09:19:31PM +0200, Marco Elver wrote: > > I was asked for input on this, and after a few days digging through some > > history, thought I'd comment. Hope you don't mind. > > Not at all, being the one that asked :-) > > > First of all, I agree with the concerns, but not because of LTO. > > > > To set the stage better, and summarize the fundamental problem again: > > we're in the unfortunate situation that no compiler today has a way to > > _efficiently_ deal with C11's memory_order_consume > > [https://lwn.net/Articles/588300/]. If we did, we could just use that > > and be done with it. But, sadly, that doesn't seem possible right now -- > > compilers just say consume==acquire. > > I'm not convinced C11 memory_order_consume would actually work for us, > even if it would work. That is, given: > > https://lore.kernel.org/lkml/20150520005510.GA23559@linux.vnet.ibm.com/ > > only pointers can have consume, but like I pointed out, we have code > that relies on dependent loads from integers. I agree that C11 memory_order_consume is not normally what we want, given that it is universally promoted to memory_order_acquire. However, dependent loads from integers are, if anything, more difficult to defend from the compiler than are control dependencies. This applies doubly to integers that are used to index two-element arrays, in which case you are just asking the compiler to destroy your dependent loads by converting them into control dependencies. > > Will suggests doing the same in the > > kernel: https://lkml.kernel.org/r/20200630173734.14057-19-will@kernel.org > > PowerPC would need a similar thing, it too will not preserve causality > for control dependecies. > > > What we're most worried about right now is the existence of compiler > > transformations that could break data dependencies by e.g. turning them > > into control dependencies. > > Correct. > > > If this is a real worry, I don't think LTO is the magical feature that > > will uncover those optimizations. If these compiler transformations are > > real, they also exist in a normal build! > > Agreed, _however_ with the caveat that LTO could make them more common. > > After all, with whole program analysis, the compiler might be able to > more easily determine that our pointer @ptr is only ever assigned the > values of &A, &B or &C, while without that visibility it would not be > able to determine this. > > Once it knows @ptr has a limited number of determined values, the > conversion into control dependencies becomes much more likely. Which would of course break dependent loads. > > And if we are worried about them, we need to stop relying on dependent > > load ordering across the board; or switch to -O0 for everything. > > Clearly, we don't want either. > > Agreed. > > > Why do we think LTO is special? > > As argued above, whole-program analysis would make it more likely. But I > agree the fundamental problem exists independent from LTO. > > > But as far as we can tell, there is no evidence of the dreaded "data > > dependency to control dependency" conversion with LTO that isn't there > > in non-LTO builds, if it's even there at all. Has the data to control > > dependency conversion been encountered in the wild? If not, is the > > resulting reaction an overreaction? If so, we need to be careful blaming > > LTO for something that it isn't even guilty of. > > It is mostly paranoia; in a large part driven by the fact that even if > such a conversion were to be done, it could go a very long time without > actually causing problems, and longer still for such problems to be > traced back to such an 'optimization'. > > That is, the collective hurt from debugging too many ordering issues. > > > So, we are probably better off untangling LTO from the story: > > > > 1. LTO or no LTO does not matter. The LTO series should not get tangled > > up with memory model issues. > > > > 2. The memory model question and problems need to be answered and > > addressed separately. > > > > Thoughts? > > How hard would it be to creates something that analyzes a build and > looks for all 'dependent load -> control dependency' transformations > headed by a volatile (and/or from asm) load and issues a warning for > them? > > This would give us an indication of how valuable this transformation is > for the kernel. I'm hoping/expecting it's vanishingly rare, but what do > I know. > This could be quite useful! Thanx, Paul
WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@kernel.org> To: Peter Zijlstra <peterz@infradead.org> Cc: linux-arch <linux-arch@vger.kernel.org>, Marco Elver <elver@google.com>, "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" <x86@kernel.org>, Kees Cook <keescook@chromium.org>, Kernel Hardening <kernel-hardening@lists.openwall.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Masahiro Yamada <masahiroy@kernel.org>, Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, LKML <linux-kernel@vger.kernel.org>, clang-built-linux <clang-built-linux@googlegroups.com>, Sami Tolvanen <samitolvanen@google.com>, linux-pci@vger.kernel.org, Will Deacon <will@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH 00/22] add support for Clang LTO Date: Tue, 30 Jun 2020 13:30:16 -0700 [thread overview] Message-ID: <20200630203016.GI9247@paulmck-ThinkPad-P72> (raw) In-Reply-To: <20200630201243.GD4817@hirez.programming.kicks-ass.net> On Tue, Jun 30, 2020 at 10:12:43PM +0200, Peter Zijlstra wrote: > On Tue, Jun 30, 2020 at 09:19:31PM +0200, Marco Elver wrote: > > I was asked for input on this, and after a few days digging through some > > history, thought I'd comment. Hope you don't mind. > > Not at all, being the one that asked :-) > > > First of all, I agree with the concerns, but not because of LTO. > > > > To set the stage better, and summarize the fundamental problem again: > > we're in the unfortunate situation that no compiler today has a way to > > _efficiently_ deal with C11's memory_order_consume > > [https://lwn.net/Articles/588300/]. If we did, we could just use that > > and be done with it. But, sadly, that doesn't seem possible right now -- > > compilers just say consume==acquire. > > I'm not convinced C11 memory_order_consume would actually work for us, > even if it would work. That is, given: > > https://lore.kernel.org/lkml/20150520005510.GA23559@linux.vnet.ibm.com/ > > only pointers can have consume, but like I pointed out, we have code > that relies on dependent loads from integers. I agree that C11 memory_order_consume is not normally what we want, given that it is universally promoted to memory_order_acquire. However, dependent loads from integers are, if anything, more difficult to defend from the compiler than are control dependencies. This applies doubly to integers that are used to index two-element arrays, in which case you are just asking the compiler to destroy your dependent loads by converting them into control dependencies. > > Will suggests doing the same in the > > kernel: https://lkml.kernel.org/r/20200630173734.14057-19-will@kernel.org > > PowerPC would need a similar thing, it too will not preserve causality > for control dependecies. > > > What we're most worried about right now is the existence of compiler > > transformations that could break data dependencies by e.g. turning them > > into control dependencies. > > Correct. > > > If this is a real worry, I don't think LTO is the magical feature that > > will uncover those optimizations. If these compiler transformations are > > real, they also exist in a normal build! > > Agreed, _however_ with the caveat that LTO could make them more common. > > After all, with whole program analysis, the compiler might be able to > more easily determine that our pointer @ptr is only ever assigned the > values of &A, &B or &C, while without that visibility it would not be > able to determine this. > > Once it knows @ptr has a limited number of determined values, the > conversion into control dependencies becomes much more likely. Which would of course break dependent loads. > > And if we are worried about them, we need to stop relying on dependent > > load ordering across the board; or switch to -O0 for everything. > > Clearly, we don't want either. > > Agreed. > > > Why do we think LTO is special? > > As argued above, whole-program analysis would make it more likely. But I > agree the fundamental problem exists independent from LTO. > > > But as far as we can tell, there is no evidence of the dreaded "data > > dependency to control dependency" conversion with LTO that isn't there > > in non-LTO builds, if it's even there at all. Has the data to control > > dependency conversion been encountered in the wild? If not, is the > > resulting reaction an overreaction? If so, we need to be careful blaming > > LTO for something that it isn't even guilty of. > > It is mostly paranoia; in a large part driven by the fact that even if > such a conversion were to be done, it could go a very long time without > actually causing problems, and longer still for such problems to be > traced back to such an 'optimization'. > > That is, the collective hurt from debugging too many ordering issues. > > > So, we are probably better off untangling LTO from the story: > > > > 1. LTO or no LTO does not matter. The LTO series should not get tangled > > up with memory model issues. > > > > 2. The memory model question and problems need to be answered and > > addressed separately. > > > > Thoughts? > > How hard would it be to creates something that analyzes a build and > looks for all 'dependent load -> control dependency' transformations > headed by a volatile (and/or from asm) load and issues a warning for > them? > > This would give us an indication of how valuable this transformation is > for the kernel. I'm hoping/expecting it's vanishingly rare, but what do > I know. > This could be quite useful! Thanx, Paul _______________________________________________ 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-06-30 20:30 UTC|newest] Thread overview: 520+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-24 20:31 [PATCH 00/22] add support for Clang LTO Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` [PATCH 01/22] objtool: use sh_info to find the base for .rela sections Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` [PATCH 02/22] kbuild: add support for Clang LTO Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:53 ` Nick Desaulniers 2020-06-24 20:53 ` Nick Desaulniers 2020-06-24 20:53 ` Nick Desaulniers 2020-06-24 21:29 ` Sami Tolvanen 2020-06-24 21:29 ` Sami Tolvanen 2020-06-25 2:26 ` Nathan Chancellor 2020-06-25 2:26 ` Nathan Chancellor 2020-06-25 16:13 ` Sami Tolvanen 2020-06-25 16:13 ` Sami Tolvanen 2020-06-24 20:31 ` [PATCH 03/22] kbuild: lto: fix module versioning Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` [PATCH 04/22] kbuild: lto: fix recordmcount Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 21:27 ` Peter Zijlstra 2020-06-24 21:27 ` Peter Zijlstra 2020-06-24 21:45 ` Sami Tolvanen 2020-06-24 21:45 ` Sami Tolvanen 2020-06-25 7:45 ` Peter Zijlstra 2020-06-25 7:45 ` Peter Zijlstra 2020-06-25 16:15 ` Sami Tolvanen 2020-06-25 16:15 ` Sami Tolvanen 2020-06-25 20:02 ` [RFC][PATCH] objtool,x86_64: Replace recordmcount with objtool Peter Zijlstra 2020-06-25 20:02 ` Peter Zijlstra 2020-06-25 20:54 ` Nick Desaulniers 2020-06-25 20:54 ` Nick Desaulniers 2020-06-25 20:54 ` Nick Desaulniers 2020-06-25 22:40 ` Sami Tolvanen 2020-06-25 22:40 ` Sami Tolvanen 2020-06-26 11:29 ` Peter Zijlstra 2020-06-26 11:29 ` Peter Zijlstra 2020-06-26 11:42 ` Peter Zijlstra 2020-06-26 11:42 ` Peter Zijlstra 2020-07-17 17:28 ` Sami Tolvanen 2020-07-17 17:28 ` Sami Tolvanen 2020-07-17 17:28 ` Sami Tolvanen 2020-07-17 17:36 ` Steven Rostedt 2020-07-17 17:36 ` Steven Rostedt 2020-07-17 17:47 ` Sami Tolvanen 2020-07-17 17:47 ` Sami Tolvanen 2020-07-17 17:47 ` Sami Tolvanen 2020-07-17 18:05 ` Steven Rostedt 2020-07-17 18:05 ` Steven Rostedt 2020-07-20 16:52 ` Sami Tolvanen 2020-07-20 16:52 ` Sami Tolvanen 2020-07-20 16:52 ` Sami Tolvanen 2020-07-22 17:58 ` Steven Rostedt 2020-07-22 17:58 ` Steven Rostedt 2020-07-22 18:07 ` Sami Tolvanen 2020-07-22 18:07 ` Sami Tolvanen 2020-07-22 18:07 ` Sami Tolvanen 2020-07-22 17:55 ` Steven Rostedt 2020-07-22 17:55 ` Steven Rostedt 2020-07-22 18:41 ` Peter Zijlstra 2020-07-22 18:41 ` Peter Zijlstra 2020-07-22 19:09 ` Steven Rostedt 2020-07-22 19:09 ` Steven Rostedt 2020-07-22 20:03 ` Sami Tolvanen 2020-07-22 20:03 ` Sami Tolvanen 2020-07-22 20:03 ` Sami Tolvanen 2020-07-22 23:56 ` Peter Zijlstra 2020-07-22 23:56 ` Peter Zijlstra 2020-07-23 0:06 ` Steven Rostedt 2020-07-23 0:06 ` Steven Rostedt 2020-08-06 22:09 ` Sami Tolvanen 2020-08-06 22:09 ` Sami Tolvanen 2020-06-24 20:31 ` [PATCH 05/22] kbuild: lto: postpone objtool Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 21:19 ` Peter Zijlstra 2020-06-24 21:19 ` Peter Zijlstra 2020-06-24 21:49 ` Sami Tolvanen 2020-06-24 21:49 ` Sami Tolvanen 2020-06-25 7:47 ` Peter Zijlstra 2020-06-25 7:47 ` Peter Zijlstra 2020-06-25 16:22 ` Sami Tolvanen 2020-06-25 16:22 ` Sami Tolvanen 2020-06-25 18:33 ` Peter Zijlstra 2020-06-25 18:33 ` Peter Zijlstra 2020-06-25 19:32 ` Sami Tolvanen 2020-06-25 19:32 ` Sami Tolvanen 2020-06-24 20:31 ` [PATCH 06/22] kbuild: lto: limit inlining Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 21:20 ` Peter Zijlstra 2020-06-24 21:20 ` Peter Zijlstra 2020-06-24 23:37 ` Sami Tolvanen 2020-06-24 23:37 ` Sami Tolvanen 2020-06-24 20:31 ` [PATCH 07/22] kbuild: lto: merge module sections Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 21:01 ` Nick Desaulniers 2020-06-24 21:01 ` Nick Desaulniers 2020-06-24 21:01 ` Nick Desaulniers 2020-06-24 21:31 ` Sami Tolvanen 2020-06-24 21:31 ` Sami Tolvanen 2020-06-24 20:31 ` [PATCH 08/22] kbuild: lto: remove duplicate dependencies from .mod files Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 21:13 ` Nick Desaulniers 2020-06-24 21:13 ` Nick Desaulniers 2020-06-24 21:13 ` Nick Desaulniers 2020-06-24 20:31 ` [PATCH 09/22] init: lto: ensure initcall ordering Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-25 0:58 ` kernel test robot 2020-06-25 0:58 ` kernel test robot 2020-06-25 0:58 ` kernel test robot 2020-06-25 4:19 ` kernel test robot 2020-06-25 4:19 ` kernel test robot 2020-06-25 4:19 ` kernel test robot 2020-06-24 20:31 ` [PATCH 10/22] init: lto: fix PREL32 relocations Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` [PATCH 11/22] pci: " Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 22:49 ` kernel test robot 2020-06-24 22:49 ` kernel test robot 2020-06-24 22:49 ` kernel test robot 2020-06-24 23:03 ` Nick Desaulniers 2020-06-24 23:03 ` Nick Desaulniers 2020-06-24 23:03 ` Nick Desaulniers 2020-06-24 23:03 ` Nick Desaulniers 2020-06-24 23:21 ` Sami Tolvanen 2020-06-24 23:21 ` Sami Tolvanen 2020-06-24 23:21 ` Sami Tolvanen 2020-07-17 20:26 ` Bjorn Helgaas 2020-07-17 20:26 ` Bjorn Helgaas 2020-07-22 18:15 ` Sami Tolvanen 2020-07-22 18:15 ` Sami Tolvanen 2020-07-22 18:15 ` Sami Tolvanen 2020-06-24 20:31 ` [PATCH 12/22] modpost: lto: strip .lto from module names Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 22:05 ` Nick Desaulniers 2020-06-24 22:05 ` Nick Desaulniers 2020-06-24 22:05 ` Nick Desaulniers 2020-06-24 20:31 ` [PATCH 13/22] scripts/mod: disable LTO for empty.c Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:57 ` Nick Desaulniers 2020-06-24 20:57 ` Nick Desaulniers 2020-06-24 20:57 ` Nick Desaulniers 2020-06-24 20:31 ` [PATCH 14/22] efi/libstub: disable LTO Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` [PATCH 15/22] drivers/misc/lkdtm: disable LTO for rodata.o Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` [PATCH 16/22] arm64: export CC_USING_PATCHABLE_FUNCTION_ENTRY Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` [PATCH 17/22] arm64: vdso: disable LTO Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:58 ` Nick Desaulniers 2020-06-24 20:58 ` Nick Desaulniers 2020-06-24 20:58 ` Nick Desaulniers 2020-06-24 21:09 ` Nick Desaulniers 2020-06-24 21:09 ` Nick Desaulniers 2020-06-24 21:09 ` Nick Desaulniers 2020-06-24 23:51 ` Andi Kleen 2020-06-24 23:51 ` Andi Kleen 2020-06-24 21:52 ` Sami Tolvanen 2020-06-24 21:52 ` Sami Tolvanen 2020-06-24 23:05 ` Nick Desaulniers 2020-06-24 23:05 ` Nick Desaulniers 2020-06-24 23:05 ` Nick Desaulniers 2020-06-24 23:39 ` Sami Tolvanen 2020-06-24 23:39 ` Sami Tolvanen 2020-06-24 20:31 ` [PATCH 18/22] arm64: allow LTO_CLANG and THINLTO to be selected Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` [PATCH 19/22] x86, vdso: disable LTO only for vDSO Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` [PATCH 20/22] x86, ftrace: disable recordmcount for ftrace_make_nop Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` [PATCH 21/22] x86, relocs: Ignore L4_PAGE_OFFSET relocations Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:31 ` Sami Tolvanen 2020-06-24 20:32 ` [PATCH 22/22] x86, build: allow LTO_CLANG and THINLTO to be selected Sami Tolvanen 2020-06-24 20:32 ` Sami Tolvanen 2020-06-24 20:32 ` Sami Tolvanen 2020-06-24 21:15 ` [PATCH 00/22] add support for Clang LTO Peter Zijlstra 2020-06-24 21:15 ` Peter Zijlstra 2020-06-24 21:30 ` Sami Tolvanen 2020-06-24 21:30 ` Sami Tolvanen 2020-06-25 8:27 ` Will Deacon 2020-06-25 8:27 ` Will Deacon 2020-06-24 21:31 ` Nick Desaulniers 2020-06-24 21:31 ` Nick Desaulniers 2020-06-24 21:31 ` Nick Desaulniers 2020-06-25 8:03 ` Peter Zijlstra 2020-06-25 8:03 ` Peter Zijlstra 2020-06-25 8:24 ` Peter Zijlstra 2020-06-25 8:24 ` Peter Zijlstra 2020-06-25 8:57 ` Peter Zijlstra 2020-06-25 8:57 ` Peter Zijlstra 2020-06-30 19:19 ` Marco Elver 2020-06-30 19:19 ` Marco Elver 2020-06-30 20:12 ` Peter Zijlstra 2020-06-30 20:12 ` Peter Zijlstra 2020-06-30 20:30 ` Paul E. McKenney [this message] 2020-06-30 20:30 ` Paul E. McKenney 2020-07-01 9:10 ` Peter Zijlstra 2020-07-01 9:10 ` Peter Zijlstra 2020-07-01 14:20 ` David Laight 2020-07-01 14:20 ` David Laight 2020-07-01 16:06 ` Paul E. McKenney 2020-07-01 16:06 ` Paul E. McKenney 2020-07-02 9:37 ` David Laight 2020-07-02 9:37 ` David Laight 2020-07-02 18:00 ` Paul E. McKenney 2020-07-02 18:00 ` Paul E. McKenney 2020-07-01 9:41 ` Marco Elver 2020-07-01 9:41 ` Marco Elver 2020-07-01 9:41 ` Marco Elver 2020-07-01 10:03 ` Will Deacon 2020-07-01 10:03 ` Will Deacon 2020-07-01 11:40 ` Peter Zijlstra 2020-07-01 11:40 ` Peter Zijlstra 2020-07-01 14:06 ` Paul E. McKenney 2020-07-01 14:06 ` Paul E. McKenney 2020-07-01 15:05 ` Peter Zijlstra 2020-07-01 15:05 ` Peter Zijlstra 2020-07-01 16:03 ` Paul E. McKenney 2020-07-01 16:03 ` Paul E. McKenney 2020-07-02 8:20 ` Peter Zijlstra 2020-07-02 8:20 ` Peter Zijlstra 2020-07-02 17:59 ` Paul E. McKenney 2020-07-02 17:59 ` Paul E. McKenney 2020-07-03 13:13 ` Peter Zijlstra 2020-07-03 13:13 ` Peter Zijlstra 2020-07-03 13:25 ` Peter Zijlstra 2020-07-03 13:25 ` Peter Zijlstra 2020-07-03 14:51 ` Paul E. McKenney 2020-07-03 14:51 ` Paul E. McKenney 2020-07-03 14:42 ` Paul E. McKenney 2020-07-03 14:42 ` Paul E. McKenney 2020-07-06 16:26 ` Paul E. McKenney 2020-07-06 16:26 ` Paul E. McKenney 2020-07-06 18:29 ` Peter Zijlstra 2020-07-06 18:29 ` Peter Zijlstra 2020-07-06 18:39 ` Paul E. McKenney 2020-07-06 18:39 ` Paul E. McKenney 2020-07-06 19:40 ` Peter Zijlstra 2020-07-06 19:40 ` Peter Zijlstra 2020-07-06 23:41 ` Paul E. McKenney 2020-07-06 23:41 ` Paul E. McKenney 2020-06-28 16:56 ` Masahiro Yamada 2020-06-28 16:56 ` Masahiro Yamada 2020-06-28 16:56 ` Masahiro Yamada 2020-06-29 23:20 ` Sami Tolvanen 2020-06-29 23:20 ` Sami Tolvanen 2020-07-07 15:51 ` Sami Tolvanen 2020-07-07 15:51 ` Sami Tolvanen 2020-07-07 16:05 ` Sami Tolvanen 2020-07-07 16:05 ` Sami Tolvanen 2020-07-07 16:56 ` Jakub Kicinski 2020-07-07 16:56 ` Jakub Kicinski 2020-07-07 17:17 ` Nick Desaulniers 2020-07-07 17:17 ` Nick Desaulniers 2020-07-07 17:17 ` Nick Desaulniers 2020-07-07 17:30 ` Jakub Kicinski 2020-07-07 17:30 ` Jakub Kicinski 2020-07-11 16:32 ` Paul Menzel 2020-07-11 16:32 ` Paul Menzel 2020-07-11 16:32 ` Paul Menzel 2020-07-12 8:59 ` Sedat Dilek 2020-07-12 8:59 ` Sedat Dilek 2020-07-12 8:59 ` Sedat Dilek 2020-07-12 18:40 ` Nathan Chancellor 2020-07-12 18:40 ` Nathan Chancellor 2020-07-14 9:44 ` Sedat Dilek 2020-07-14 9:44 ` Sedat Dilek 2020-07-14 9:44 ` Sedat Dilek 2020-07-14 17:54 ` Nick Desaulniers 2020-07-14 17:54 ` Nick Desaulniers 2020-07-14 17:54 ` Nick Desaulniers 2020-07-12 23:34 ` Sami Tolvanen 2020-07-12 23:34 ` Sami Tolvanen 2020-07-12 23:34 ` Sami Tolvanen 2020-07-14 12:16 ` Paul Menzel 2020-07-14 12:16 ` Paul Menzel 2020-07-14 12:35 ` Sedat Dilek 2020-07-14 12:35 ` Sedat Dilek 2020-07-14 12:35 ` Sedat Dilek 2020-07-14 13:40 ` Paul Menzel 2020-09-03 20:30 ` [PATCH v2 00/28] Add " Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` [PATCH v2 01/28] x86/boot/compressed: Disable relocation relaxation Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 21:44 ` Kees Cook 2020-09-03 21:44 ` Kees Cook 2020-09-03 23:42 ` Arvind Sankar 2020-09-03 23:42 ` Arvind Sankar 2020-09-04 7:14 ` Nathan Chancellor 2020-09-04 7:14 ` Nathan Chancellor 2020-09-06 3:16 ` Sasha Levin 2020-09-03 20:30 ` [PATCH v2 02/28] x86/asm: Replace __force_order with memory clobber Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 21:45 ` Kees Cook 2020-09-03 21:45 ` Kees Cook 2020-09-03 20:30 ` [PATCH v2 03/28] lib/string.c: implement stpcpy Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 21:47 ` Kees Cook 2020-09-03 21:47 ` Kees Cook 2020-09-06 3:16 ` Sasha Levin 2020-09-03 20:30 ` [PATCH v2 04/28] RAS/CEC: Fix cec_init() prototype Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 21:50 ` Kees Cook 2020-09-03 21:50 ` Kees Cook 2020-09-03 20:30 ` [PATCH v2 05/28] objtool: Add a pass for generating __mcount_loc Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 21:51 ` Kees Cook 2020-09-03 21:51 ` Kees Cook 2020-09-03 22:03 ` Sami Tolvanen 2020-09-03 22:03 ` Sami Tolvanen 2020-09-03 22:03 ` Sami Tolvanen 2020-09-04 9:31 ` peterz 2020-09-04 9:31 ` peterz 2020-09-10 18:29 ` Kees Cook 2020-09-10 18:29 ` Kees Cook 2020-09-03 20:30 ` [PATCH v2 06/28] objtool: Don't autodetect vmlinux.o Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 21:52 ` Kees Cook 2020-09-03 21:52 ` Kees Cook 2020-09-03 20:30 ` [PATCH v2 07/28] kbuild: add support for objtool mcount Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 21:56 ` Kees Cook 2020-09-03 21:56 ` Kees Cook 2020-09-03 20:30 ` [PATCH v2 08/28] x86, build: use " Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 21:58 ` Kees Cook 2020-09-03 21:58 ` Kees Cook 2020-09-03 22:11 ` Sami Tolvanen 2020-09-03 22:11 ` Sami Tolvanen 2020-09-03 22:11 ` Sami Tolvanen 2020-09-03 20:30 ` [PATCH v2 09/28] kbuild: add support for Clang LTO Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:08 ` Kees Cook 2020-09-03 22:08 ` Kees Cook 2020-09-08 17:02 ` Sami Tolvanen 2020-09-08 17:02 ` Sami Tolvanen 2020-09-05 19:36 ` Masahiro Yamada 2020-09-05 19:36 ` Masahiro Yamada 2020-09-08 17:10 ` Sami Tolvanen 2020-09-08 17:10 ` Sami Tolvanen 2020-09-05 20:17 ` Masahiro Yamada 2020-09-05 20:17 ` Masahiro Yamada 2020-09-08 17:14 ` Sami Tolvanen 2020-09-08 17:14 ` Sami Tolvanen 2020-09-07 15:30 ` Masahiro Yamada 2020-09-07 15:30 ` Masahiro Yamada 2020-09-08 17:30 ` Sami Tolvanen 2020-09-08 17:30 ` Sami Tolvanen 2020-09-03 20:30 ` [PATCH v2 10/28] kbuild: lto: fix module versioning Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:11 ` Kees Cook 2020-09-03 22:11 ` Kees Cook 2020-09-08 18:23 ` Sami Tolvanen 2020-09-08 18:23 ` Sami Tolvanen 2020-09-03 20:30 ` [PATCH v2 11/28] kbuild: lto: postpone objtool Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:19 ` Kees Cook 2020-09-03 22:19 ` Kees Cook 2020-09-08 20:56 ` Sami Tolvanen 2020-09-08 20:56 ` Sami Tolvanen 2020-09-03 20:30 ` [PATCH v2 12/28] kbuild: lto: limit inlining Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:20 ` Kees Cook 2020-09-03 22:20 ` Kees Cook 2020-09-03 20:30 ` [PATCH v2 13/28] kbuild: lto: merge module sections Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:23 ` Kees Cook 2020-09-03 22:23 ` Kees Cook 2020-09-07 15:25 ` Masahiro Yamada 2020-09-07 15:25 ` Masahiro Yamada 2020-09-08 21:07 ` Sami Tolvanen 2020-09-08 21:07 ` Sami Tolvanen 2020-09-03 20:30 ` [PATCH v2 14/28] kbuild: lto: remove duplicate dependencies from .mod files Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:29 ` Kees Cook 2020-09-03 22:29 ` Kees Cook 2020-09-03 20:30 ` [PATCH v2 15/28] init: lto: ensure initcall ordering Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:40 ` Kees Cook 2020-09-03 22:40 ` Kees Cook 2020-09-08 21:16 ` Sami Tolvanen 2020-09-08 21:16 ` Sami Tolvanen 2020-09-10 9:25 ` David Woodhouse 2020-09-10 9:25 ` David Woodhouse 2020-09-10 9:25 ` David Woodhouse 2020-09-10 15:07 ` Sami Tolvanen 2020-09-10 15:07 ` Sami Tolvanen 2020-09-03 20:30 ` [PATCH v2 16/28] init: lto: fix PREL32 relocations Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:41 ` Kees Cook 2020-09-03 22:41 ` Kees Cook 2020-09-06 3:16 ` Sasha Levin 2020-09-03 20:30 ` [PATCH v2 17/28] PCI: Fix PREL32 relocations for LTO Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:42 ` Kees Cook 2020-09-03 22:42 ` Kees Cook 2020-09-03 20:30 ` [PATCH v2 18/28] modpost: lto: strip .lto from module names Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:42 ` Kees Cook 2020-09-03 22:42 ` Kees Cook 2020-09-03 20:30 ` [PATCH v2 19/28] scripts/mod: disable LTO for empty.c Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:43 ` Kees Cook 2020-09-03 22:43 ` Kees Cook 2020-09-03 20:30 ` [PATCH v2 20/28] efi/libstub: disable LTO Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:43 ` Kees Cook 2020-09-03 22:43 ` Kees Cook 2020-09-03 20:30 ` [PATCH v2 21/28] drivers/misc/lkdtm: disable LTO for rodata.o Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` [PATCH v2 22/28] arm64: export CC_USING_PATCHABLE_FUNCTION_ENTRY Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:44 ` Kees Cook 2020-09-03 22:44 ` Kees Cook 2020-09-08 21:23 ` Sami Tolvanen 2020-09-08 21:23 ` Sami Tolvanen 2020-09-03 20:30 ` [PATCH v2 23/28] arm64: vdso: disable LTO Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:45 ` Kees Cook 2020-09-03 22:45 ` Kees Cook 2020-09-03 20:30 ` [PATCH v2 24/28] KVM: arm64: disable LTO for the nVHE directory Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:45 ` Kees Cook 2020-09-03 22:45 ` Kees Cook 2020-09-03 20:30 ` [PATCH v2 25/28] arm64: allow LTO_CLANG and THINLTO to be selected Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:45 ` Kees Cook 2020-09-03 22:45 ` Kees Cook 2020-09-03 20:30 ` [PATCH v2 26/28] x86, vdso: disable LTO only for vDSO Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:46 ` Kees Cook 2020-09-03 22:46 ` Kees Cook 2020-09-03 20:30 ` [PATCH v2 27/28] x86, relocs: Ignore L4_PAGE_OFFSET relocations Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:47 ` Kees Cook 2020-09-03 22:47 ` Kees Cook 2020-09-08 23:28 ` Sami Tolvanen 2020-09-08 23:28 ` Sami Tolvanen 2020-09-03 20:30 ` [PATCH v2 28/28] x86, build: allow LTO_CLANG and THINLTO to be selected Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 20:30 ` Sami Tolvanen 2020-09-03 22:48 ` Kees Cook 2020-09-03 22:48 ` Kees Cook 2020-09-03 23:34 ` [PATCH v2 00/28] Add support for Clang LTO Kees Cook 2020-09-03 23:34 ` Kees Cook 2020-09-04 4:45 ` Nathan Chancellor 2020-09-04 4:45 ` Nathan Chancellor 2020-09-03 23:38 ` Kees Cook 2020-09-03 23:38 ` Kees Cook 2020-09-04 7:53 ` Sedat Dilek 2020-09-04 7:53 ` Sedat Dilek 2020-09-04 7:53 ` Sedat Dilek 2020-09-04 8:55 ` peterz 2020-09-04 8:55 ` peterz 2020-09-04 9:08 ` Sedat Dilek 2020-09-04 9:08 ` Sedat Dilek 2020-09-04 9:08 ` Sedat Dilek 2020-09-06 0:24 ` Masahiro Yamada 2020-09-06 0:24 ` Masahiro Yamada 2020-09-08 23:46 ` Sami Tolvanen 2020-09-08 23:46 ` Sami Tolvanen 2020-09-10 1:18 ` Masahiro Yamada 2020-09-10 1:18 ` Masahiro Yamada 2020-09-10 15:17 ` Sami Tolvanen 2020-09-10 15:17 ` Sami Tolvanen 2020-09-10 18:18 ` Kees Cook 2020-09-10 18:18 ` Kees Cook 2020-09-10 17:46 ` Nick Desaulniers 2020-09-10 18:07 ` Masahiro Yamada 2020-09-22 16:27 ` [EXTERNAL] " Ian Bearman 2020-09-22 17:52 ` Nick Desaulniers
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=20200630203016.GI9247@paulmck-ThinkPad-P72 \ --to=paulmck@kernel.org \ --cc=clang-built-linux@googlegroups.com \ --cc=elver@google.com \ --cc=gregkh@linuxfoundation.org \ --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=peterz@infradead.org \ --cc=samitolvanen@google.com \ --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.