Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
From: Will Deacon <will@kernel.org>
To: Marco Elver <elver@google.com>
Cc: linux-arch <linux-arch@vger.kernel.org>,
	"maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)"
	<x86@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>,
	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,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 00/22] add support for Clang LTO
Date: Wed, 1 Jul 2020 11:03:59 +0100
Message-ID: <20200701100358.GA14959@willie-the-truck> (raw)
In-Reply-To: <CANpmjNP+7TtE0WPU=nX5zs3T2+4hPkkm08meUm2VDVY3RgsHDw@mail.gmail.com>

On Wed, Jul 01, 2020 at 11:41:17AM +0200, Marco Elver wrote:
> On Tue, 30 Jun 2020 at 22:30, Paul E. McKenney <paulmck@kernel.org> wrote:
> > 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:
> > > > 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?
> 
> I was thinking about this, but in the context of the "auto-promote to
> acquire" which you didn't like. Issuing a warning should certainly be
> simpler.
> 
> I think there is no one place where we know these transformations
> happen, but rather, need to analyze the IR before transformations,
> take note of all the dependent loads headed by volatile+asm, and then
> run an analysis after optimizations checking the dependencies are
> still there.
> 
> > > 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!
> 
> We might then even be able to say, "if you get this warning, turn on
> CONFIG_ACQUIRE_READ_DEPENDENCIES" (or however the option will be
> named). Or some other tricks, like automatically recompile the TU
> where this happens with the option. But again, this is not something
> that should specifically block LTO, because if we have this, we'll
> need to turn it on for everything.

I'm not especially keen on solving this with additional config options --
all it does it further fragment the number of kernels we have to care about
and distributions really won't be in a position to know whether this should
be enabled or not. I would prefer that the build fails, and we figure out
which compiler switch we need to stop the harmful optimisation taking place.
As Peter says, it _should_ be a rare thing to see (empirically, the kernel
seems to be getting away with it so far).

The problem, as I see it, is that the C language doesn't provide us with
a way to express dependency ordering and so we're at the mercy of the
compiler when we roll our own implementation. Paul continues to fight the
good fight at committee meetings to improve the situation, but in the
meantime we'd benefit from two things:

  1. A way to disable any compiler optimisations that break our dependency
     ordering in spite of READ_ONCE()

  2. A way to detect at build time if these harmful optimisations are taking
     place

Finally, while I agree that this problem isn't limited to LTO, my fear is
that LTO provides enough information for address dependencies headed by
a READ_ONCE() to be converted to control dependencies when some common
values of the pointer can be determined by the compiler. If we can rule
this sort of thing out, then great, but in the absence of (2) I think
throwing in an acquire is a sensible safety measure. Doesn't CFI rely
on LTO to do something similar for indirect branch targets, or have I
got that totally mixed up?

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply index

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 ` [PATCH 02/22] kbuild: add support for Clang LTO Sami Tolvanen
2020-06-24 20:53   ` Nick Desaulniers
2020-06-24 21:29     ` Sami Tolvanen
2020-06-25  2:26   ` Nathan Chancellor
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 ` [PATCH 04/22] kbuild: lto: fix recordmcount Sami Tolvanen
2020-06-24 21:27   ` Peter Zijlstra
2020-06-24 21:45     ` Sami Tolvanen
2020-06-25  7:45       ` Peter Zijlstra
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:54             ` Nick Desaulniers
2020-06-25 22:40             ` Sami Tolvanen
2020-06-26 11:29               ` Peter Zijlstra
2020-06-26 11:42                 ` Peter Zijlstra
2020-06-24 20:31 ` [PATCH 05/22] kbuild: lto: postpone objtool Sami Tolvanen
2020-06-24 21:19   ` Peter Zijlstra
2020-06-24 21:49     ` Sami Tolvanen
2020-06-25  7:47       ` Peter Zijlstra
2020-06-25 16:22         ` Sami Tolvanen
2020-06-25 18:33           ` Peter Zijlstra
2020-06-25 19:32             ` Sami Tolvanen
2020-06-24 20:31 ` [PATCH 06/22] kbuild: lto: limit inlining Sami Tolvanen
2020-06-24 21:20   ` Peter Zijlstra
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 21:01   ` Nick Desaulniers
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 21:13   ` Nick Desaulniers
2020-06-24 20:31 ` [PATCH 09/22] init: lto: ensure initcall ordering Sami Tolvanen
2020-06-25  0:58   ` 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 ` [PATCH 11/22] pci: " Sami Tolvanen
2020-06-24 22:49   ` kernel test robot
2020-06-24 23:03     ` Nick Desaulniers
2020-06-24 23:21       ` Sami Tolvanen
2020-06-24 20:31 ` [PATCH 12/22] modpost: lto: strip .lto from module names Sami Tolvanen
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:57   ` Nick Desaulniers
2020-06-24 20:31 ` [PATCH 14/22] efi/libstub: disable LTO 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 ` [PATCH 16/22] arm64: export CC_USING_PATCHABLE_FUNCTION_ENTRY Sami Tolvanen
2020-06-24 20:31 ` [PATCH 17/22] arm64: vdso: disable LTO Sami Tolvanen
2020-06-24 20:58   ` Nick Desaulniers
2020-06-24 21:09     ` Nick Desaulniers
2020-06-24 23:51       ` Andi Kleen
2020-06-24 21:52     ` Sami Tolvanen
2020-06-24 23:05       ` Nick Desaulniers
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 ` [PATCH 19/22] x86, vdso: disable LTO only for vDSO 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 ` [PATCH 21/22] x86, relocs: Ignore L4_PAGE_OFFSET relocations 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 21:15 ` [PATCH 00/22] add support for Clang LTO Peter Zijlstra
2020-06-24 21:30   ` Sami Tolvanen
2020-06-25  8:27     ` Will Deacon
2020-06-24 21:31   ` Nick Desaulniers
2020-06-25  8:03     ` Peter Zijlstra
2020-06-25  8:24       ` Peter Zijlstra
2020-06-25  8:57         ` Peter Zijlstra
2020-06-30 19:19           ` Marco Elver
2020-06-30 20:12             ` Peter Zijlstra
2020-06-30 20:30               ` Paul E. McKenney
2020-07-01  9:10                 ` Peter Zijlstra
2020-07-01 14:20                   ` David Laight
2020-07-01 16:06                     ` Paul E. McKenney
2020-07-02  9:37                       ` David Laight
2020-07-02 18:00                         ` Paul E. McKenney
2020-07-01  9:41                 ` Marco Elver
2020-07-01 10:03                   ` Will Deacon [this message]
2020-07-01 11:40                   ` Peter Zijlstra
2020-07-01 14:06                     ` Paul E. McKenney
2020-07-01 15:05                       ` Peter Zijlstra
2020-07-01 16:03                         ` Paul E. McKenney
2020-07-02  8:20                           ` Peter Zijlstra
2020-07-02 17:59                             ` Paul E. McKenney
2020-07-03 13:13                               ` Peter Zijlstra
2020-07-03 13:25                                 ` Peter Zijlstra
2020-07-03 14:51                                   ` Paul E. McKenney
2020-07-03 14:42                                 ` Paul E. McKenney
2020-07-06 16:26                                   ` Paul E. McKenney
2020-07-06 18:29                                     ` Peter Zijlstra
2020-07-06 18:39                                       ` Paul E. McKenney
2020-07-06 19:40                                         ` Peter Zijlstra
2020-07-06 23:41                                           ` Paul E. McKenney
2020-06-28 16:56 ` Masahiro Yamada
2020-06-29 23:20   ` 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=20200701100358.GA14959@willie-the-truck \
    --to=will@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=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=samitolvanen@google.com \
    --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: link

Linux-ARM-Kernel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ https://lore.kernel.org/linux-arm-kernel \
		linux-arm-kernel@lists.infradead.org
	public-inbox-index linux-arm-kernel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git