From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1C523C433E0 for ; Wed, 1 Jul 2020 10:05:22 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DFF032073E for ; Wed, 1 Jul 2020 10:05:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="s5DZfohs"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ACTOMog6" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DFF032073E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=OfK4zfRLIGvUh9TDLIgjay7WOl1JeBVpTxZ6u37KsBY=; b=s5DZfohsNT2RCgx709qX8vaXk h61Ki/Fk1d8UXecmI5fkAhhiXSZA0bhDVkS9RD8ydqlYk5B2DUkM75FYUnrGrsZqjGzqeRulBUq6U Tu0TcNIl0f+TWrDeMq8sYhh/z66z0ju+j/TZtWb2ocmX3SngxsKXt+Z8s5/nkLupTRI9MCbfR6xnf Pc0Ef9hrjD5LGU+FbiABIp4hs1E+Tv+ajEvbK36Kt18LAvleHgKtY+cPqVVK2v2BjAK9AtWwK3d1k dy4FAawIRg3chRkSxVNQmVdd3mraL+iudxoJZquKCAOVVqMQDeLXAgSqSf0y9eRdX6zAHhOy/SX9E 1PzC+6INQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqZb7-0006Dw-85; Wed, 01 Jul 2020 10:04:09 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqZb3-0006CW-PO for linux-arm-kernel@lists.infradead.org; Wed, 01 Jul 2020 10:04:07 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4A0092073E; Wed, 1 Jul 2020 10:04:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593597844; bh=TNs9dwunGLESHIUTn3WPSH+kJ4ymDC60LJKhDKcwQ+E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ACTOMog6G7ls0ARoC7jAptS3bHf4H/M+sf80vr+5+gHs+a+qnec0OCDmenyBz9hA4 JvZrijIz9n77vFlikbI+f42x1lmidFrYxvr9l9eKKfMFWvHcDZD1Um+tcsybykZPp5 hmi3Id23gmOaZNr6xrgZarcWcGcX/fdtKQ8k6vy4= Date: Wed, 1 Jul 2020 11:03:59 +0100 From: Will Deacon To: Marco Elver Subject: Re: [PATCH 00/22] add support for Clang LTO Message-ID: <20200701100358.GA14959@willie-the-truck> References: <20200624203200.78870-1-samitolvanen@google.com> <20200624211540.GS4817@hirez.programming.kicks-ass.net> <20200625080313.GY4817@hirez.programming.kicks-ass.net> <20200625082433.GC117543@hirez.programming.kicks-ass.net> <20200625085745.GD117543@hirez.programming.kicks-ass.net> <20200630191931.GA884155@elver.google.com> <20200630201243.GD4817@hirez.programming.kicks-ass.net> <20200630203016.GI9247@paulmck-ThinkPad-P72> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200701_060406_036318_C9D66F38 X-CRM114-Status: GOOD ( 31.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , Kees Cook , "Paul E. McKenney" , Kernel Hardening , Peter Zijlstra , Greg Kroah-Hartman , Masahiro Yamada , Linux Kbuild mailing list , Nick Desaulniers , LKML , clang-built-linux , Sami Tolvanen , linux-pci@vger.kernel.org, Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jul 01, 2020 at 11:41:17AM +0200, Marco Elver wrote: > On Tue, 30 Jun 2020 at 22:30, Paul E. McKenney 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