Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1822350ybt; Thu, 2 Jul 2020 15:02:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwagoSiEJjl47An48pEfFyJCOPJRzdVoA7Ak1gmAkARnq+EJBADBTTNRcOR0PTPf+yyb1sS X-Received: by 2002:a17:906:3b83:: with SMTP id u3mr28712724ejf.207.1593727351884; Thu, 02 Jul 2020 15:02:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593727351; cv=none; d=google.com; s=arc-20160816; b=xcSwCOd941jBe7fbqRM/Ga05KhfBnDyVcsBLYvAqVtN3B+o78UWdtFnrOxnwpkbJ6Y AfCZLEWgQe9NRX7EMg7nXzU4YNohC2+r6uPDk1CB/uukxYw5UdULSmJ6P8fCt8XD4oqE vhYxSSb1hkTW13p/DFgn/E+v51gofLLnQcx7QSxgaMjitDFVfsHf8AhhzJgJRz0Pv+/+ rW5MRAGHU2+1TqLB9fHWtcXaiRuBF5DnxJvdUno9+WmZynRX/f+BdIxbPa9RCde0huZ0 GjU8EQc391DNE0NLVXiYjK8vp8H8EymYn7PZuae2xfi5nmZX3qYYpTD/P5lXPniYi5cT V7zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:cc:to:from:date:references :in-reply-to:message-id:mime-version:user-agent:dkim-signature :dkim-signature; bh=++Nf+jzmk32Uv4KzN6LP0cOsHrUI9EjgYva0jX6LIrU=; b=NyfCasD1F5m+Xg/fyL3VXn5+sLRXHwej6HZkRVdRmBePgrFs1Gaw9cK5XaILaapEp5 IzHsOVHZD3g4CoNDwwINdDH/rZ1njp9fxp5MgcIesc689B1ERWdKlmYpMkk44QIisk/7 FfHu+98CWbgegYZLBMI9ZNdkdRc9Os8l6zj1CoqvDdjQPHxMMWw7u6wX9bYTcHQCboe2 Bo9kxuFBEAn5FzvCGLSAO+1sO/+vsfZKCLwyufOF2nmeplshUAQQUMBjSPO/S5/Qv0wn km4KmCisMkDO7/HnwAnkrZQxJZFV+acdBFJqWMRaa0JiigEUed+mOXA4ON0Mz4Bqwrpy Qq1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kdrag0n.dev header.s=fm1 header.b=Pg4yk0YI; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=PhkQcYY6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=kdrag0n.dev Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r23si7277999edb.72.2020.07.02.15.02.08; Thu, 02 Jul 2020 15:02:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kdrag0n.dev header.s=fm1 header.b=Pg4yk0YI; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=PhkQcYY6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=kdrag0n.dev Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726364AbgGBWBt (ORCPT + 99 others); Thu, 2 Jul 2020 18:01:49 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:44131 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726347AbgGBWBs (ORCPT ); Thu, 2 Jul 2020 18:01:48 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E57215C0184; Thu, 2 Jul 2020 18:01:46 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute1.internal (MEProxy); Thu, 02 Jul 2020 18:01:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kdrag0n.dev; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=++Nf+jzmk32Uv4KzN6LP0cOsHrUI9Ej gYva0jX6LIrU=; b=Pg4yk0YIJrwWMjzDqS+aUUqvdlNb82l4y6EkYHpGnzP70f7 B1YY40jKsE2vbdvE0u+udHjX9YrAvotz+e5OdBfaJsnBOtxSz4u06wG++5PLV+Vk 1HmRpvbrHXzaAKDsPStHWr42Y+8wrseqKfCCHrhLiae2YLg9K3dZcZBXeWkJ5Bk6 mHrFGZhVgmu55nr8o1J5Isiw/wPi6NUodV2SJNJjWHIlPBy9UXmWDJDw/tXZ5ecG Xf5Cp1WCkhqZ97Hv6PdOli47zBcoBWFcxy0s5L0YAUXDvLZYNfnNAL2PvzIGNTkw 3Yn+QjwqghBEkeIb4SVTqaI4fv7diXTn4LauhMw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=++Nf+j zmk32Uv4KzN6LP0cOsHrUI9EjgYva0jX6LIrU=; b=PhkQcYY6l8VzCLSHHcxsfJ FswLbAHWfg7HrJmtCqZlsos0DeSMz6ig3H8wT2YEGMmzuFKYnHf41PJVYGpmEflZ SDjp7Hjh6ZW+eW7VLeOB13VO8pkMtqmDVTRHtThjuA9U+KULZJzRUpWa7bmVZoWz brdzPcM9y7j7nBWW/JdP6i200Ffowb8ZfRznAL7xCSIdxPCAlSYcmvI8iYhk5sMe 82Sca2cF1KLVll9kwTGZJfEBhvA/q2XrCYcSLZwimGE+VScCLNDRb4oEQQm3RqOx Wckjaj+83NTBUUrHXvE1oCevJM83DZAobdwVvucj0FZf/1JwH2Z/cGN6Ub67k1ig == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtdehgddtfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedfffgrnhhn hicunfhinhdfuceouggrnhhnhieskhgurhgrghdtnhdruggvvheqnecuggftrfgrthhtvg hrnhepvedvkeefhfejtdfgleegudeujeeuueehtddvudffkeegjeejfeffvdeuteektdeg necuffhomhgrihhnpehgohhoghhlvghsohhurhgtvgdrtghomhdpghhithhhuhgsrdgtoh hmpdhlphgsgidruggrthgrpdhkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegurghnnhihsehkughrrghgtdhnrdguvg hv X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1791B1400A1; Thu, 2 Jul 2020 18:01:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668 Mime-Version: 1.0 Message-Id: <7304fdf3-23d7-442b-b870-e88ae6f37004@localhost> In-Reply-To: <20200702160420.GA3512364@ubuntu-s3-xlarge-x86> References: <20200702085400.2643527-1-danny@kdrag0n.dev> <202007020853.5F15B5DDD@keescook> <20200702160420.GA3512364@ubuntu-s3-xlarge-x86> Date: Thu, 02 Jul 2020 15:01:25 -0700 From: "Danny Lin" To: "Nathan Chancellor" Cc: "Kees Cook" , "Arnd Bergmann" , "Nick Desaulniers" , "Sami Tolvanen" , "Fangrui Song" , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com, stable@vger.kernel.org Subject: =?UTF-8?Q?Re:_[PATCH]_vmlinux.lds.h:_Coalesce_transient_LLVM_dead_code_e?= =?UTF-8?Q?limination_sections?= Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jul 2, 2020 9:04:25 AM Nathan Chancellor : > On Thu, Jul 02, 2020 at 08:54:53AM -0700, Kees Cook wrote: >> On Thu, Jul 02, 2020 at 01:54:00AM -0700, Danny Lin wrote: >>> A recent LLVM 11 commit [1] made LLD stop implicitly coalescing some >>> temporary LLVM sections, namely .{data,bss}..compoundliteral.XXX: >>> >>> [30] .data..compoundli PROGBITS ffffffff9ac9a000 19e9a000 >>> 000000000000cea0 0000000000000000 WA 0 0 32 >>> [31] .rela.data..compo RELA 0000000000000000 40965440 >>> 0000000000001d88 0000000000000018 I 2238 30 8 >>> [32] .data..compoundli PROGBITS ffffffff9aca6ea0 19ea6ea0 >>> 00000000000033c0 0000000000000000 WA 0 0 32 >>> [33] .rela.data..compo RELA 0000000000000000 409671c8 >>> 0000000000000948 0000000000000018 I 2238 32 8 >>> [...] >>> [2213] .bss..compoundlit NOBITS ffffffffa3000000 1d85c000 >>> 00000000000000a0 0000000000000000 WA 0 0 32 >>> [2214] .bss..compoundlit NOBITS ffffffffa30000a0 1d85c000 >>> 0000000000000040 0000000000000000 WA 0 0 32 >>> [...] >>> >>> While these extra sections don't typically cause any breakage, they do >>> inflate the vmlinux size due to the overhead of storing metadata for >>> thousands of extra sections. >>> >>> It's also worth noting that for some reason, some downstream Android >>> kernels can't boot at all if these sections aren't coalesced. >>> >>> This issue isn't limited to any specific architecture; it affects arm64 >>> and x86 if CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is forced on. > > It might be worth noting that this happens explicitly because of > -fdata-sections, which is currently only used with > CONFIG_LD_DEAD_CODE_DATA_ELIMINATION but there are other features such > as LTO that will enable this and make this relevant in the future. > > https://android-review.googlesource.com/c/kernel/common/+/1329278/6#message-81b191e92ef4e98e017fa9ded5ef63ef6e60db3a > > It is also worth noting that those commits add .bss..L* and .data..L* > and rodata variants. Do you know if those are relevant here? As far as I can tell, those sections are exclusive to LTO which isn't in mainline yet. I don't see any sections like that in my DCE-only vmlinux. > >>> Example on x86 allyesconfig: >>> Before: 2241 sections, 1170972 KiB >>> After: 56 sections, 1171169 KiB > > Am I reading this right that coalescing those sections increases the > image size? Kind of interesting. Oops, I accidentally swapped the numbers in the commit message. Coalescing the sections makes the image smaller as expected. > >>> [1] https://github.com/llvm/llvm-project/commit/9e33c096476ab5e02ab1c8442cc3cb4e32e29f17 >>> >>> Link: https://github.com/ClangBuiltLinux/linux/issues/958 >>> Cc: stable@vger.kernel.org # v4.4+ >>> Suggested-by: Fangrui Song >>> Signed-off-by: Danny Lin > > Reviewed-by: Nathan Chancellor > >>> --- >>> include/asm-generic/vmlinux.lds.h | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h >>> index db600ef218d7..18968cba87c7 100644 >>> --- a/include/asm-generic/vmlinux.lds.h >>> +++ b/include/asm-generic/vmlinux.lds.h >>> @@ -94,10 +94,10 @@ >>> */ >>> #ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION >>> #define TEXT_MAIN .text .text.[0-9a-zA-Z_]* >>> -#define DATA_MAIN .data .data.[0-9a-zA-Z_]* .data..LPBX* >>> +#define DATA_MAIN .data .data.[0-9a-zA-Z_]* .data..LPBX* .data..compoundliteral* > > I am fairly certain this will fix a PowerPC warning that we had > recently so good! > > https://lore.kernel.org/lkml/202006180904.TVUXCf6H%25lkp@intel.com/ > > Unfortunately, I forgot to reply to that thread... > >>> #define SDATA_MAIN .sdata .sdata.[0-9a-zA-Z_]* >>> #define RODATA_MAIN .rodata .rodata.[0-9a-zA-Z_]* >>> -#define BSS_MAIN .bss .bss.[0-9a-zA-Z_]* >>> +#define BSS_MAIN .bss .bss.[0-9a-zA-Z_]* .bss..compoundliteral* >> >> Are there .data.. and .bss.. sections we do NOT want to collect? i.e. >> why not include .data..* and .bss..* ? > > At one point Android was doing that for modules but stopped: > > https://android-review.googlesource.com/c/kernel/common/+/1266787 > > I wonder if that is a problem for the main kernel image. A comment above the code in question explicitly states that not all .data..* sections should be coalesced. There's a .data..percpu section in my x86 vmlinux which should probably remain separate. > > Cheers, > Nathan >