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=-13.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 0C52CC64E8A for ; Wed, 2 Dec 2020 05:47:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9F3A9221FA for ; Wed, 2 Dec 2020 05:47:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728481AbgLBFr1 (ORCPT ); Wed, 2 Dec 2020 00:47:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46730 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726125AbgLBFr1 (ORCPT ); Wed, 2 Dec 2020 00:47:27 -0500 Received: from mail-vk1-xa42.google.com (mail-vk1-xa42.google.com [IPv6:2607:f8b0:4864:20::a42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 23417C0613D4 for ; Tue, 1 Dec 2020 21:46:47 -0800 (PST) Received: by mail-vk1-xa42.google.com with SMTP id m6so147844vkl.2 for ; Tue, 01 Dec 2020 21:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zIYg3wn3IiOAwIUjN3HHnL/xxZ7BzmV6ArGGQCieAHY=; b=bON2yGnfCiyS2deASK7lq7vUUxyZx+TcNqxyx0Y2lzXGXaJk2/GGL6wVTlpf746M17 ewSfrj7S9dsZKHz9EXsFml/ZRzW3ibKt2hylTzUrhiQailV3BSYLijuRVIlNThE7Ss7H KnWN0tGzIrPrfvFAOAvf+8FI8ABAECA3BAv1o2Nf8hdcpJnE2U+4ENVHLDfsMJ2syTzS iaGmOfE/X9XwWP/ylcYRN5sQKiXL7/ZHlVEs4e0tCksSkzjQe+RVz9j9FQbs4OUZPc8T CR1MgHpyNAn/FzhGrLr7gcE7qYAYqX3l4Q2HISPXD2rjqVZX7wjj378ggI/rHdDvjDb8 F84w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zIYg3wn3IiOAwIUjN3HHnL/xxZ7BzmV6ArGGQCieAHY=; b=EIcAIbW/pDTsFRr329eyuicoczT+QVRK9a8lJocyEznzdK1EDY6/gBhhwPFcGG5QP5 QBaJukTE5lJcW1UilRpDWf9Sb/N9a4YtMOz8DXLw0K/GzO2MFGyISwOJux9Wqj+0Zkj7 Pwf3doshusbZcaGs5XJ9tNt2X4fQKCnCYqESQjJWzVZ9is0UVUna38ufQdLp8xZ+rs5l 8Xv5Jy3UUzTQSxXasS0PEOxAYJt8TbG/zWS/qJwRg/k4UVhjESrpQYk7cMX9Pm3M/f9G G3GcaCqCA794BZnKBbFnwDxd/gDj0IEXDl8llZeHoXcvTbPk0K2YN2VhKZSiyL+RboJK mdBQ== X-Gm-Message-State: AOAM531FSmaLhTAEfUg9GjmhI6MxH8s7gvsmUI91QMloLsqpyIXRSBSE 9IzN6xkGPFZXrEz5BylPp4ihJATpVtshnnlhYLXqww== X-Google-Smtp-Source: ABdhPJyfTarblbQWXQ2D0gqGJIM068ljJFblRKN2s+iu0HTYtaH2RdablEmO5KmOvdnbvJUKStvPOuGuLcyF9JZVZE8= X-Received: by 2002:a1f:36d4:: with SMTP id d203mr580407vka.22.1606888005927; Tue, 01 Dec 2020 21:46:45 -0800 (PST) MIME-Version: 1.0 References: <20201118220731.925424-1-samitolvanen@google.com> <20201130120130.GF24563@willie-the-truck> <202012010929.3788AF5@keescook> In-Reply-To: From: Sami Tolvanen Date: Tue, 1 Dec 2020 21:46:33 -0800 Message-ID: Subject: Re: [PATCH v7 00/17] Add support for Clang LTO To: Masahiro Yamada Cc: Kees Cook , Will Deacon , Steven Rostedt , Josh Poimboeuf , Peter Zijlstra , Greg Kroah-Hartman , "Paul E. McKenney" , Nick Desaulniers , clang-built-linux , Kernel Hardening , linux-arch , linux-arm-kernel , Linux Kbuild mailing list , Linux Kernel Mailing List , PCI Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 1, 2020 at 6:43 PM Masahiro Yamada wrote: > > On Wed, Dec 2, 2020 at 2:31 AM Kees Cook wrote: > > > > On Mon, Nov 30, 2020 at 12:01:31PM +0000, Will Deacon wrote: > > > Hi Sami, > > > > > > On Wed, Nov 18, 2020 at 02:07:14PM -0800, Sami Tolvanen wrote: > > > > This patch series adds support for building the kernel with Clang's > > > > Link Time Optimization (LTO). In addition to performance, the primary > > > > motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to > > > > be used in the kernel. Google has shipped millions of Pixel devices > > > > running three major kernel versions with LTO+CFI since 2018. > > > > > > > > Most of the patches are build system changes for handling LLVM bitcode, > > > > which Clang produces with LTO instead of ELF object files, postponing > > > > ELF processing until a later stage, and ensuring initcall ordering. > > > > > > > > Note that v7 brings back arm64 support as Will has now staged the > > > > prerequisite memory ordering patches [1], and drops x86_64 while we work > > > > on fixing the remaining objtool warnings [2]. > > > > > > Sounds like you're going to post a v8, but that's the plan for merging > > > that? The arm64 parts look pretty good to me now. > > > > I haven't seen Masahiro comment on this in a while, so given the review > > history and its use (for years now) in Android, I will carry v8 (assuming > > all is fine with it) it in -next unless there are objections. > > > What I dislike about this implementation is > it cannot drop any unreachable function/data. > (and it is completely different from GCC LTO) > > This is not real LTO. I'm not sure I understand your concern. LTO cannot drop functions or data from vmlinux.o that may be referenced externally. However, with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, the linker certainly can drop unused functions and data when linking vmlinux, and there's no reason this option can't be used together with LTO. In fact, Pixel 3 does enable this option, but in our experience, there isn't much unused code or data to remove, so later devices no longer use it. There's technically no reason why we couldn't postpone LTO until we link vmlinux instead, and thus allow the linker to possibly remove more unused code without the help of --gc-sections, but at least with the current build process, that would involve performing the slow LTO link step multiple times, which isn't worth it when we can get the performance benefits (and CFI) already when linking vmlinux.o with LTO. Sami 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=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 79D96C64E7C for ; Wed, 2 Dec 2020 05:48:03 +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 13ED1221FA for ; Wed, 2 Dec 2020 05:48:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 13ED1221FA Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com 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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=t5ghJbN1KG3He6u1YC7MZiUkOoS6d7wxirgk92Aq9F4=; b=Z30DelBV/bXxWruT4tAyIon30 j36cwTvjFIOPv0SgoVvdxvFU9wORwL+0Zte7jvCZHzhBM9K6Oa3VnXzUUOAKsz3ZpXJ6hE9HcQurF HqdRISJCa0oXs+x/3VHcMb2H3fU9E3AryABOeEcXp+SO/oSffHwca5GQ3G0F4+SFHYUmI+D7s63O1 hSraHF8Zul+BhzE7XL8o146O829mkAvngdzbxDCHISsG4gneQkX8TuvaDyo1i2QUYl3PbA+adq0vm a4y7g/Ap/r0LvQVhJ3uqkJL2bq7GsI6ufvmBM5fp88XF0NlMxYZcQz7xuIWTGfewXeRGrRspMr7W+ HD3VnWapg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kkKyY-00033k-Fj; Wed, 02 Dec 2020 05:46:50 +0000 Received: from mail-vk1-xa44.google.com ([2607:f8b0:4864:20::a44]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kkKyW-00032x-A3 for linux-arm-kernel@lists.infradead.org; Wed, 02 Dec 2020 05:46:49 +0000 Received: by mail-vk1-xa44.google.com with SMTP id s135so145066vkh.6 for ; Tue, 01 Dec 2020 21:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zIYg3wn3IiOAwIUjN3HHnL/xxZ7BzmV6ArGGQCieAHY=; b=bON2yGnfCiyS2deASK7lq7vUUxyZx+TcNqxyx0Y2lzXGXaJk2/GGL6wVTlpf746M17 ewSfrj7S9dsZKHz9EXsFml/ZRzW3ibKt2hylTzUrhiQailV3BSYLijuRVIlNThE7Ss7H KnWN0tGzIrPrfvFAOAvf+8FI8ABAECA3BAv1o2Nf8hdcpJnE2U+4ENVHLDfsMJ2syTzS iaGmOfE/X9XwWP/ylcYRN5sQKiXL7/ZHlVEs4e0tCksSkzjQe+RVz9j9FQbs4OUZPc8T CR1MgHpyNAn/FzhGrLr7gcE7qYAYqX3l4Q2HISPXD2rjqVZX7wjj378ggI/rHdDvjDb8 F84w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zIYg3wn3IiOAwIUjN3HHnL/xxZ7BzmV6ArGGQCieAHY=; b=t2IdCUduD53V/F85Nanaxxf5szK0ItLfN8U4ZpEYoOlvf70DzPALo3j9tMrJSEa1p3 CqVXRxxFjCu58S1s+L5KUKbhZ/ynQW/ESs+Hs1aSKcSjpwNxcS/ueFBgfVAW1fGv425w 5jSjcBWM+1wVBpkl3MYHAO8bXl3LwwrSS2aMItypTsO0zcjC/+OTN5CPG1gIvIzW5y20 5m/rtbk2yQ+zwRmikM2PrIJR95yuXhlPvNd34rzfiVWVO7ENeYfkFPfD+BRgKoZWOSPi mUSIvhrgxJndmHKXGMGhClHXCGv6G64LkurJm9RNPkcKufX8jaEirrl5A5AvoeZTOj4q kKdA== X-Gm-Message-State: AOAM532Rp3up75GrkUqisH5Axcu/b7xhPnKJS8faziwuB0d7Ty4YfLxE Me6kUFsRHZaWrL/hkKpnlfeAkO6au5jGxfuVz68bFQ== X-Google-Smtp-Source: ABdhPJyfTarblbQWXQ2D0gqGJIM068ljJFblRKN2s+iu0HTYtaH2RdablEmO5KmOvdnbvJUKStvPOuGuLcyF9JZVZE8= X-Received: by 2002:a1f:36d4:: with SMTP id d203mr580407vka.22.1606888005927; Tue, 01 Dec 2020 21:46:45 -0800 (PST) MIME-Version: 1.0 References: <20201118220731.925424-1-samitolvanen@google.com> <20201130120130.GF24563@willie-the-truck> <202012010929.3788AF5@keescook> In-Reply-To: From: Sami Tolvanen Date: Tue, 1 Dec 2020 21:46:33 -0800 Message-ID: Subject: Re: [PATCH v7 00/17] Add support for Clang LTO To: Masahiro Yamada X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201202_004648_411362_B96DD5AC X-CRM114-Status: GOOD ( 30.63 ) 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 , Kees Cook , "Paul E. McKenney" , Kernel Hardening , Peter Zijlstra , Greg Kroah-Hartman , Linux Kbuild mailing list , Nick Desaulniers , Linux Kernel Mailing List , Steven Rostedt , clang-built-linux , PCI , Josh Poimboeuf , Will Deacon , linux-arm-kernel 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 Tue, Dec 1, 2020 at 6:43 PM Masahiro Yamada wrote: > > On Wed, Dec 2, 2020 at 2:31 AM Kees Cook wrote: > > > > On Mon, Nov 30, 2020 at 12:01:31PM +0000, Will Deacon wrote: > > > Hi Sami, > > > > > > On Wed, Nov 18, 2020 at 02:07:14PM -0800, Sami Tolvanen wrote: > > > > This patch series adds support for building the kernel with Clang's > > > > Link Time Optimization (LTO). In addition to performance, the primary > > > > motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to > > > > be used in the kernel. Google has shipped millions of Pixel devices > > > > running three major kernel versions with LTO+CFI since 2018. > > > > > > > > Most of the patches are build system changes for handling LLVM bitcode, > > > > which Clang produces with LTO instead of ELF object files, postponing > > > > ELF processing until a later stage, and ensuring initcall ordering. > > > > > > > > Note that v7 brings back arm64 support as Will has now staged the > > > > prerequisite memory ordering patches [1], and drops x86_64 while we work > > > > on fixing the remaining objtool warnings [2]. > > > > > > Sounds like you're going to post a v8, but that's the plan for merging > > > that? The arm64 parts look pretty good to me now. > > > > I haven't seen Masahiro comment on this in a while, so given the review > > history and its use (for years now) in Android, I will carry v8 (assuming > > all is fine with it) it in -next unless there are objections. > > > What I dislike about this implementation is > it cannot drop any unreachable function/data. > (and it is completely different from GCC LTO) > > This is not real LTO. I'm not sure I understand your concern. LTO cannot drop functions or data from vmlinux.o that may be referenced externally. However, with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, the linker certainly can drop unused functions and data when linking vmlinux, and there's no reason this option can't be used together with LTO. In fact, Pixel 3 does enable this option, but in our experience, there isn't much unused code or data to remove, so later devices no longer use it. There's technically no reason why we couldn't postpone LTO until we link vmlinux instead, and thus allow the linker to possibly remove more unused code without the help of --gc-sections, but at least with the current build process, that would involve performing the slow LTO link step multiple times, which isn't worth it when we can get the performance benefits (and CFI) already when linking vmlinux.o with LTO. Sami _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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=-13.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 A6F1BC64E8A for ; Wed, 2 Dec 2020 05:47:07 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id 7F179221FE for ; Wed, 2 Dec 2020 05:47:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7F179221FE Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-20509-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 20391 invoked by uid 550); 2 Dec 2020 05:46:58 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 20367 invoked from network); 2 Dec 2020 05:46:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zIYg3wn3IiOAwIUjN3HHnL/xxZ7BzmV6ArGGQCieAHY=; b=bON2yGnfCiyS2deASK7lq7vUUxyZx+TcNqxyx0Y2lzXGXaJk2/GGL6wVTlpf746M17 ewSfrj7S9dsZKHz9EXsFml/ZRzW3ibKt2hylTzUrhiQailV3BSYLijuRVIlNThE7Ss7H KnWN0tGzIrPrfvFAOAvf+8FI8ABAECA3BAv1o2Nf8hdcpJnE2U+4ENVHLDfsMJ2syTzS iaGmOfE/X9XwWP/ylcYRN5sQKiXL7/ZHlVEs4e0tCksSkzjQe+RVz9j9FQbs4OUZPc8T CR1MgHpyNAn/FzhGrLr7gcE7qYAYqX3l4Q2HISPXD2rjqVZX7wjj378ggI/rHdDvjDb8 F84w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zIYg3wn3IiOAwIUjN3HHnL/xxZ7BzmV6ArGGQCieAHY=; b=GgOkz4HRETxotDZSKyQXjpUHaX65XFkzFmH5zYCPLAqSWGXFZXjnA+drbdcRIBSQ5N /zFyrJaxA7nzhTvdshFwMVoOhv2OO2l7aPNe1aNDPWnvLybTr3VoMFMMGhcbFfW1XDOm h/csY29u6e2vdSe1L1ryKUvbjZl/nBo5p/VbDg1Uu9Ih7M7fFPiVPpuoIT41+ECHywBL OhKVcL9opdjBibh6jWdO9EOxr8VEdQ5e+pWksDWIX69neHsGu6Uap/TCcLfJXrlGZLeF 1bDLpS7s/e3X9jRHSirpJnVO7PA1GjK8uxOMSurJWHIpM6A3FV35p4gMuWNm85ZcuhIU VdaQ== X-Gm-Message-State: AOAM5304RRzPLbfw+XDARDuxaRWlubA4LiC+oazrsQ08Gpht3ZpVS6uI U03TWtKwsbACk60mZ3CgTXMXklXaOglfOua5zWMKzQ== X-Google-Smtp-Source: ABdhPJyfTarblbQWXQ2D0gqGJIM068ljJFblRKN2s+iu0HTYtaH2RdablEmO5KmOvdnbvJUKStvPOuGuLcyF9JZVZE8= X-Received: by 2002:a1f:36d4:: with SMTP id d203mr580407vka.22.1606888005927; Tue, 01 Dec 2020 21:46:45 -0800 (PST) MIME-Version: 1.0 References: <20201118220731.925424-1-samitolvanen@google.com> <20201130120130.GF24563@willie-the-truck> <202012010929.3788AF5@keescook> In-Reply-To: From: Sami Tolvanen Date: Tue, 1 Dec 2020 21:46:33 -0800 Message-ID: Subject: Re: [PATCH v7 00/17] Add support for Clang LTO To: Masahiro Yamada Cc: Kees Cook , Will Deacon , Steven Rostedt , Josh Poimboeuf , Peter Zijlstra , Greg Kroah-Hartman , "Paul E. McKenney" , Nick Desaulniers , clang-built-linux , Kernel Hardening , linux-arch , linux-arm-kernel , Linux Kbuild mailing list , Linux Kernel Mailing List , PCI Content-Type: text/plain; charset="UTF-8" On Tue, Dec 1, 2020 at 6:43 PM Masahiro Yamada wrote: > > On Wed, Dec 2, 2020 at 2:31 AM Kees Cook wrote: > > > > On Mon, Nov 30, 2020 at 12:01:31PM +0000, Will Deacon wrote: > > > Hi Sami, > > > > > > On Wed, Nov 18, 2020 at 02:07:14PM -0800, Sami Tolvanen wrote: > > > > This patch series adds support for building the kernel with Clang's > > > > Link Time Optimization (LTO). In addition to performance, the primary > > > > motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to > > > > be used in the kernel. Google has shipped millions of Pixel devices > > > > running three major kernel versions with LTO+CFI since 2018. > > > > > > > > Most of the patches are build system changes for handling LLVM bitcode, > > > > which Clang produces with LTO instead of ELF object files, postponing > > > > ELF processing until a later stage, and ensuring initcall ordering. > > > > > > > > Note that v7 brings back arm64 support as Will has now staged the > > > > prerequisite memory ordering patches [1], and drops x86_64 while we work > > > > on fixing the remaining objtool warnings [2]. > > > > > > Sounds like you're going to post a v8, but that's the plan for merging > > > that? The arm64 parts look pretty good to me now. > > > > I haven't seen Masahiro comment on this in a while, so given the review > > history and its use (for years now) in Android, I will carry v8 (assuming > > all is fine with it) it in -next unless there are objections. > > > What I dislike about this implementation is > it cannot drop any unreachable function/data. > (and it is completely different from GCC LTO) > > This is not real LTO. I'm not sure I understand your concern. LTO cannot drop functions or data from vmlinux.o that may be referenced externally. However, with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, the linker certainly can drop unused functions and data when linking vmlinux, and there's no reason this option can't be used together with LTO. In fact, Pixel 3 does enable this option, but in our experience, there isn't much unused code or data to remove, so later devices no longer use it. There's technically no reason why we couldn't postpone LTO until we link vmlinux instead, and thus allow the linker to possibly remove more unused code without the help of --gc-sections, but at least with the current build process, that would involve performing the slow LTO link step multiple times, which isn't worth it when we can get the performance benefits (and CFI) already when linking vmlinux.o with LTO. Sami