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=-12.1 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,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 01581C4741F for ; Wed, 30 Sep 2020 22:13:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B66A1206FC for ; Wed, 30 Sep 2020 22:13:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="vIRIWKYp" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731034AbgI3WND (ORCPT ); Wed, 30 Sep 2020 18:13:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731000AbgI3WNC (ORCPT ); Wed, 30 Sep 2020 18:13:02 -0400 Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D199FC0613D2 for ; Wed, 30 Sep 2020 15:13:01 -0700 (PDT) Received: by mail-ed1-x544.google.com with SMTP id b12so3530557edz.11 for ; Wed, 30 Sep 2020 15:13:01 -0700 (PDT) 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=/5JyINSMzWB8voXWZyV8ASlSh5pqRDmgZFl229b53xc=; b=vIRIWKYp7RTSUGB8ntUgtpTfuIX9PNECXrtz7OF4WuzjxaB6ucqKe+labxFFw91k3e QxLYAkxotsyYRcimIeAn7Z8xictu3hpLg464s+yhLPGoBBznroXq6KWSnvggTT+OKc+4 aDiohWxi2bv6qcv/jsb8X6MLhFKoc5VlhLVAgI9mvRP+ESLwvXgjzFulM/aycHPXZ43C 1PZWgQU//0UlvKQQQTsVxdhKKn2R1cZHSse1ucxAjFxlIjoTBB5mxWh5AjLIfsBpQ8Qr kwHSrW70qM469yHzjDZCiyJ6JH0YYN8N5o79By5EDLYjMuAR2Pr4Z/ShSwy2ytzZ+9o+ xxNw== 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=/5JyINSMzWB8voXWZyV8ASlSh5pqRDmgZFl229b53xc=; b=MDr9odjs6qdHC+j/Dox8kTfnZzvlcAaykNzqFzZSLTC9PnCYmtF6+mqcCQRLXUTrY3 6aNz51DJMAKDCdecDOY4tOrshGCAsw3ZdAkauJYgB9DFIXgjxTvQU/H5F7b0gGjaGBWd SSluSO7V5Nfpk07k7n29Zc9tQsiEYHLMEuKFuE6V3GlnUPGZFB2cj4bZpKArN+Wzsfyr m344co0DXr0k/U+iyYSziD6fnrT48h1DQ4y2m7Wq7C4YsVAnm2F96ZbHrRaFsQwGbbUs fKV+z8TvmCn9DXeFfyfo6SkFY1HM2i9jn+2w4OpOE45r4xYXn9jEhl09W+iLCacOSIpM xlBg== X-Gm-Message-State: AOAM531RERFRAfDoi3+e+79X5W09P4JMjlbQ6UANGuaY8+8LGEWGgRW7 1zILTMz0jr6zcU6XP1HerowjIObcBP2PpIAyiUBktQ== X-Google-Smtp-Source: ABdhPJzjWahTDCS64Nwdg2Qz+9IkGNUdbgNKy/rFx3FC7CVjfHrBmMTaxElMCOz9QatJ5KolJbRCcmnwy3926ope18M= X-Received: by 2002:aa7:c0d3:: with SMTP id j19mr5304520edp.40.1601503980129; Wed, 30 Sep 2020 15:13:00 -0700 (PDT) MIME-Version: 1.0 References: <20200929214631.3516445-1-samitolvanen@google.com> In-Reply-To: From: Sami Tolvanen Date: Wed, 30 Sep 2020 15:12:49 -0700 Message-ID: Subject: Re: [PATCH v4 00/29] Add support for Clang LTO To: Nick Desaulniers , Peter Zijlstra Cc: Masahiro Yamada , Will Deacon , Steven Rostedt , Greg Kroah-Hartman , "Paul E. McKenney" , Kees Cook , clang-built-linux , Kernel Hardening , linux-arch , Linux ARM , Linux Kbuild mailing list , LKML , linux-pci@vger.kernel.org, "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 30, 2020 at 2:58 PM Nick Desaulniers wrote: > > On Tue, Sep 29, 2020 at 2:46 PM Sami Tolvanen wrote: > > > > This patch series adds support for building x86_64 and arm64 kernels > > 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. > > Sami, thanks for continuing to drive the series. I encourage you to > keep resending with fixes accumulated or dropped on a weekly cadence. > > The series worked well for me on arm64, but for x86_64 on mainline I > saw a stream of new objtool warnings: [...] Objtool normally won't print out these warnings when run on vmlinux.o, but we can't pass --vmlinux to objtool as that also implies noinstr validation right now. I think we'd have to split that from --vmlinux to avoid these. I can include a patch to add a --noinstr flag in v5. Peter, any thoughts about this? > I think those should be resolved before I provide any kind of tested > by tag. My other piece of feedback was that I like the default > ThinLTO, but I think the help text in the Kconfig which is visible > during menuconfig could be improved by informing the user the > tradeoffs. For example, if CONFIG_THINLTO is disabled, it should be > noted that full LTO will be used instead. Also, that full LTO may > produce slightly better optimized binaries than ThinLTO, at the cost > of not utilizing multiple cores when linking and thus significantly > slower to link. > > Maybe explaining that setting it to "n" implies a full LTO build, > which will be much slower to link but possibly slightly faster would > be good? It's not visible unless LTO_CLANG and ARCH_SUPPORTS_THINLTO > is enabled, so I don't think you need to explain that THINLTO without > those is *not* full LTO. I'll leave the precise wording to you. WDYT? Sure, sounds good. I'll update the help text in the next version. > Also, when I look at your treewide DISABLE_LTO patch, I think "does > that need to be a part of this series, or is it a cleanup that can > stand on its own?" I think it may be the latter? Maybe it would help > shed one more patch than to have to carry it to just send it? Or did > I miss something as to why it should remain a part of this series? I suppose it could be stand-alone, but as these patches are also disabling LTO by filtering out flags in some of the same files, removing the unused DISABLE_LTO flags first would reduce confusion. But I'm fine with sending it separately too if that's preferred. 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=-4.5 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 9B17CC4363D for ; Wed, 30 Sep 2020 22:14:27 +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 3E7FB20719 for ; Wed, 30 Sep 2020 22:14:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="MG0KYLI1"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="vIRIWKYp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3E7FB20719 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=qiwaZGUmFmrgN0D9aAa6IkdrejozZQJUSiJygG/p3J4=; b=MG0KYLI1vWS+m45D/Ih/EMPdE iK+lRDAy0Ih8V22yLJh7lTPCFfgzRFzRxyqLBmrhQbSYGPoUpc+LdGFwvY6Ekxi5OYyTuWZD5P6kB bJR6YDf9ZCy4K1c50IZVtYtLm1iGqKl/O2H1oEAAkKrR+WO9Lpd4SOVW7QinqtcvXztj11KzO5791 c7dib9FNG6ZinUiO3PrPtql6mVECLnyoNoQBHDUoz/RkswAdnpW1VzMx8VHek4PLIwBnUwGLnnfdX OgU/JQFm6MWW5Ovcm3CXYr9fFSbwL6qrnSX6llYrBfO+V6NuRHlVASWYxKJQ5eK+1E0+dB3hCEQp5 urc3Bw3Qg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNkLR-00051R-T1; Wed, 30 Sep 2020 22:13:05 +0000 Received: from mail-ed1-x543.google.com ([2a00:1450:4864:20::543]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNkLO-00050D-Jp for linux-arm-kernel@lists.infradead.org; Wed, 30 Sep 2020 22:13:03 +0000 Received: by mail-ed1-x543.google.com with SMTP id j2so3537927eds.9 for ; Wed, 30 Sep 2020 15:13:01 -0700 (PDT) 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=/5JyINSMzWB8voXWZyV8ASlSh5pqRDmgZFl229b53xc=; b=vIRIWKYp7RTSUGB8ntUgtpTfuIX9PNECXrtz7OF4WuzjxaB6ucqKe+labxFFw91k3e QxLYAkxotsyYRcimIeAn7Z8xictu3hpLg464s+yhLPGoBBznroXq6KWSnvggTT+OKc+4 aDiohWxi2bv6qcv/jsb8X6MLhFKoc5VlhLVAgI9mvRP+ESLwvXgjzFulM/aycHPXZ43C 1PZWgQU//0UlvKQQQTsVxdhKKn2R1cZHSse1ucxAjFxlIjoTBB5mxWh5AjLIfsBpQ8Qr kwHSrW70qM469yHzjDZCiyJ6JH0YYN8N5o79By5EDLYjMuAR2Pr4Z/ShSwy2ytzZ+9o+ xxNw== 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=/5JyINSMzWB8voXWZyV8ASlSh5pqRDmgZFl229b53xc=; b=b/JVmaOy1H/Wb3BNJpI+imrCu8ag2jb1Q1rTqTlAF9f3O0sDjdoS1p6JPJYf0/vFxP 4Ls5zvO9SzOkxlvasXKFVJNHAhD2Vn3hoATlDBiwED+t2y5dn2pNarHjr6aEXfio/hfc wKg7rikVFAZ6QuhLFq0tMoskdpTokud9sMPQzUF4Ilzv+RovB2c2xFo2vNTainWEfBE7 Oaq/TT5tBF4zpSW6irgGUVR5gidr6gUAGdSmJjW52ffCdwE1dZaAEuY3NRAX693Ys87r zZBkqCh7HZR3jInAvL9SlucvvrX9Ph10LCoyPUD5mCVTPyZbWRGLLGvOs76zmktlB5bk d1kQ== X-Gm-Message-State: AOAM533yRX3Nu+mMNEs7HFUOBnHu/mCK+kzg2GibzCRcSppSYZETUHF2 ecUHGUHg4B+K3w9ANsDHqEsb5JMRwPYL93I3+eOjbA== X-Google-Smtp-Source: ABdhPJzjWahTDCS64Nwdg2Qz+9IkGNUdbgNKy/rFx3FC7CVjfHrBmMTaxElMCOz9QatJ5KolJbRCcmnwy3926ope18M= X-Received: by 2002:aa7:c0d3:: with SMTP id j19mr5304520edp.40.1601503980129; Wed, 30 Sep 2020 15:13:00 -0700 (PDT) MIME-Version: 1.0 References: <20200929214631.3516445-1-samitolvanen@google.com> In-Reply-To: From: Sami Tolvanen Date: Wed, 30 Sep 2020 15:12:49 -0700 Message-ID: Subject: Re: [PATCH v4 00/29] Add support for Clang LTO To: Nick Desaulniers , Peter Zijlstra X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200930_181303_074923_F664954B X-CRM114-Status: GOOD ( 33.93 ) 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 , Greg Kroah-Hartman , Masahiro Yamada , Linux Kbuild mailing list , LKML , Steven Rostedt , clang-built-linux , linux-pci@vger.kernel.org, Will Deacon , 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, Sep 30, 2020 at 2:58 PM Nick Desaulniers wrote: > > On Tue, Sep 29, 2020 at 2:46 PM Sami Tolvanen wrote: > > > > This patch series adds support for building x86_64 and arm64 kernels > > 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. > > Sami, thanks for continuing to drive the series. I encourage you to > keep resending with fixes accumulated or dropped on a weekly cadence. > > The series worked well for me on arm64, but for x86_64 on mainline I > saw a stream of new objtool warnings: [...] Objtool normally won't print out these warnings when run on vmlinux.o, but we can't pass --vmlinux to objtool as that also implies noinstr validation right now. I think we'd have to split that from --vmlinux to avoid these. I can include a patch to add a --noinstr flag in v5. Peter, any thoughts about this? > I think those should be resolved before I provide any kind of tested > by tag. My other piece of feedback was that I like the default > ThinLTO, but I think the help text in the Kconfig which is visible > during menuconfig could be improved by informing the user the > tradeoffs. For example, if CONFIG_THINLTO is disabled, it should be > noted that full LTO will be used instead. Also, that full LTO may > produce slightly better optimized binaries than ThinLTO, at the cost > of not utilizing multiple cores when linking and thus significantly > slower to link. > > Maybe explaining that setting it to "n" implies a full LTO build, > which will be much slower to link but possibly slightly faster would > be good? It's not visible unless LTO_CLANG and ARCH_SUPPORTS_THINLTO > is enabled, so I don't think you need to explain that THINLTO without > those is *not* full LTO. I'll leave the precise wording to you. WDYT? Sure, sounds good. I'll update the help text in the next version. > Also, when I look at your treewide DISABLE_LTO patch, I think "does > that need to be a part of this series, or is it a cleanup that can > stand on its own?" I think it may be the latter? Maybe it would help > shed one more patch than to have to carry it to just send it? Or did > I miss something as to why it should remain a part of this series? I suppose it could be stand-alone, but as these patches are also disabling LTO by filtering out flags in some of the same files, removing the unused DISABLE_LTO flags first would reduce confusion. But I'm fine with sending it separately too if that's preferred. 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=-12.1 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,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 6BC51C4363D for ; Wed, 30 Sep 2020 22:13:19 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id A7D1D206F7 for ; Wed, 30 Sep 2020 22:13:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="vIRIWKYp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A7D1D206F7 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-20074-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 28560 invoked by uid 550); 30 Sep 2020 22:13:12 -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 28521 invoked from network); 30 Sep 2020 22:13:11 -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=/5JyINSMzWB8voXWZyV8ASlSh5pqRDmgZFl229b53xc=; b=vIRIWKYp7RTSUGB8ntUgtpTfuIX9PNECXrtz7OF4WuzjxaB6ucqKe+labxFFw91k3e QxLYAkxotsyYRcimIeAn7Z8xictu3hpLg464s+yhLPGoBBznroXq6KWSnvggTT+OKc+4 aDiohWxi2bv6qcv/jsb8X6MLhFKoc5VlhLVAgI9mvRP+ESLwvXgjzFulM/aycHPXZ43C 1PZWgQU//0UlvKQQQTsVxdhKKn2R1cZHSse1ucxAjFxlIjoTBB5mxWh5AjLIfsBpQ8Qr kwHSrW70qM469yHzjDZCiyJ6JH0YYN8N5o79By5EDLYjMuAR2Pr4Z/ShSwy2ytzZ+9o+ xxNw== 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=/5JyINSMzWB8voXWZyV8ASlSh5pqRDmgZFl229b53xc=; b=BwwAXhk/QxEIlr6iHRvTGHuqi5Dd5fofiy1GT84wjxDj3tGNSoOWTKptrOegIgXTj9 1aheFwfyMsEleua5D1ZbztUdCaqxzltY9b+ZmlNIrXTZs8Y5voTeKIF8NsCiuVM9IHQi u9KQ497g3SBOAaXYWqUUWs1MkvCMEayUFlBvEpZPIeYHpBYcC4Dy9CU7UxtI4pu/pFIF oEOq9ajy3i9yWZPgW1vN65/bBeI2CMh/76lxK+eH7aqxNQoYSt0L0qiqPd6/1W6cLSil 7KHmLGBLah+3GeKziyjdkTHH3/+aNQx/Jic3BPuLzryb95LHyyOCrRCuhwn+/E3dfMJT LHvw== X-Gm-Message-State: AOAM530jv2LAoYJNsqH6/t9CC4A0PRH/lW5rc0QEc7pO348Z5ro8tHoQ QQ4e5CYFwbMwlAJO7Duv/hwB+28rJLU2n8FLK/oOfg== X-Google-Smtp-Source: ABdhPJzjWahTDCS64Nwdg2Qz+9IkGNUdbgNKy/rFx3FC7CVjfHrBmMTaxElMCOz9QatJ5KolJbRCcmnwy3926ope18M= X-Received: by 2002:aa7:c0d3:: with SMTP id j19mr5304520edp.40.1601503980129; Wed, 30 Sep 2020 15:13:00 -0700 (PDT) MIME-Version: 1.0 References: <20200929214631.3516445-1-samitolvanen@google.com> In-Reply-To: From: Sami Tolvanen Date: Wed, 30 Sep 2020 15:12:49 -0700 Message-ID: Subject: Re: [PATCH v4 00/29] Add support for Clang LTO To: Nick Desaulniers , Peter Zijlstra Cc: Masahiro Yamada , Will Deacon , Steven Rostedt , Greg Kroah-Hartman , "Paul E. McKenney" , Kees Cook , clang-built-linux , Kernel Hardening , linux-arch , Linux ARM , Linux Kbuild mailing list , LKML , linux-pci@vger.kernel.org, "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" Content-Type: text/plain; charset="UTF-8" On Wed, Sep 30, 2020 at 2:58 PM Nick Desaulniers wrote: > > On Tue, Sep 29, 2020 at 2:46 PM Sami Tolvanen wrote: > > > > This patch series adds support for building x86_64 and arm64 kernels > > 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. > > Sami, thanks for continuing to drive the series. I encourage you to > keep resending with fixes accumulated or dropped on a weekly cadence. > > The series worked well for me on arm64, but for x86_64 on mainline I > saw a stream of new objtool warnings: [...] Objtool normally won't print out these warnings when run on vmlinux.o, but we can't pass --vmlinux to objtool as that also implies noinstr validation right now. I think we'd have to split that from --vmlinux to avoid these. I can include a patch to add a --noinstr flag in v5. Peter, any thoughts about this? > I think those should be resolved before I provide any kind of tested > by tag. My other piece of feedback was that I like the default > ThinLTO, but I think the help text in the Kconfig which is visible > during menuconfig could be improved by informing the user the > tradeoffs. For example, if CONFIG_THINLTO is disabled, it should be > noted that full LTO will be used instead. Also, that full LTO may > produce slightly better optimized binaries than ThinLTO, at the cost > of not utilizing multiple cores when linking and thus significantly > slower to link. > > Maybe explaining that setting it to "n" implies a full LTO build, > which will be much slower to link but possibly slightly faster would > be good? It's not visible unless LTO_CLANG and ARCH_SUPPORTS_THINLTO > is enabled, so I don't think you need to explain that THINLTO without > those is *not* full LTO. I'll leave the precise wording to you. WDYT? Sure, sounds good. I'll update the help text in the next version. > Also, when I look at your treewide DISABLE_LTO patch, I think "does > that need to be a part of this series, or is it a cleanup that can > stand on its own?" I think it may be the latter? Maybe it would help > shed one more patch than to have to carry it to just send it? Or did > I miss something as to why it should remain a part of this series? I suppose it could be stand-alone, but as these patches are also disabling LTO by filtering out flags in some of the same files, removing the unused DISABLE_LTO flags first would reduce confusion. But I'm fine with sending it separately too if that's preferred. Sami