Received: by 2002:a05:6a10:c7c6:0:0:0:0 with SMTP id h6csp37776pxy; Fri, 30 Jul 2021 23:04:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwG8qGIo5wyM5zM5sZ5dHPo3OHZgkZcMIeV9s1mXAfOnM7jb/W4X7eACZBRybdga+4HjMpr X-Received: by 2002:aa7:c489:: with SMTP id m9mr7537136edq.256.1627711456849; Fri, 30 Jul 2021 23:04:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627711456; cv=none; d=google.com; s=arc-20160816; b=vKnp5oV1zk1A6tK3Aq61vJux7xbHIMsU3KPfDbahUL9pc/XHW//rMmdyV3XACAcdsP llSPOwHZ3wjfqQsoizjkNmk8FB568hiDz3h4MKHTrcwSAkETP9el11uOLURixDsruVe0 hNdYkyL8luISluCfdGvIiDC8qt+wmIBKycU3l/A1OMisYP+TSeYkTh5y0twYJnkpRkti H4SFqP2F2v3yW2MSWsPWyuqSaqplcVPtUTA45occRZX4V1S5n8+4o80cJms9EhkX+L4E Ia20a5JrD9jw+mUv8WXURSP9VOWndwJwzgSnk456rdFirC9xSG6FyGykktpMYDHbFMLy Yhww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=RnJbeFRABx8gv+E+NAXey4lvwWkcIEVkiEIkxS1UNwc=; b=NYrr5jNaO5mYw6JAZ4uURSW7pnOsNmAqjN4aKD5N1yKDlnJClZXaBH2jdB9Xu6sULB fhYRdnkPbARy5tGqCifKDmWyGx7Z94dflZmlhYFBm/JuOfdzNXQlTw9eBkGLyicSvDmq pVqACtsSk6bB5ic7L6YZIzLNLykfdZHjd6KcJgBr0cCpMIOxsLNjkWM+Xb/XxiMh2T6M IfdaNw+8t1Y88FIrfv9JWnVth+r5q+GLuRq78OzsFxXaqo+6t/5mCxnyUQp2+dOuXVtK MSxZXz/q1YebC0/yaHzQu9YiLMG0tlRuEMRjuVC5Xn+4ftXAJHc5rR48RViv1ll6wron HxVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=azNSPWyE; 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=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u24si3929376edo.515.2021.07.30.23.03.53; Fri, 30 Jul 2021 23:04:16 -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=@google.com header.s=20161025 header.b=azNSPWyE; 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=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236711AbhGaGBQ (ORCPT + 99 others); Sat, 31 Jul 2021 02:01:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43526 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236495AbhGaGBO (ORCPT ); Sat, 31 Jul 2021 02:01:14 -0400 Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50327C0613CF for ; Fri, 30 Jul 2021 23:01:09 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id a20so13663718plm.0 for ; Fri, 30 Jul 2021 23:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=RnJbeFRABx8gv+E+NAXey4lvwWkcIEVkiEIkxS1UNwc=; b=azNSPWyE526BJD25Kig41e/gXZuaCnVwVtmfP/XFktm31kW6IWgDV558SlzkEo/XN6 aJjHbwyHPNxcpZyhqo3fDd3UiLK7HBtztgkTaq3x3JKUITY/O2N3Zemakxue44EvrNx8 vrZZf6hRZbsoBPAsWiiMWzGR2Xu9cw6oyHzRzhPmaglu1tsu3ZGZ6Q50dYJz70t6S8vm u8kyWdLjAPRBQ2YyckxY631Voo/H2xTYGz6YznrmzzRZpvUE+yWJcBNfSWBUecvR9MKF DY7vxvbSItyF/XXB9m9a5aoe6FxDRpAkuYyYSQ0qrO8Ms41bXxw4WcMuRcJcNsGVEAWw yu4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=RnJbeFRABx8gv+E+NAXey4lvwWkcIEVkiEIkxS1UNwc=; b=OFcIbb+1+3dBI+1M2wV4evQK5lcPNmBJspmKS17uQ+FmqUfmoTmZj80cLl0OEBdEPs v7XckOeON4VoVnZ0DKKIgGKFtx1kdO+s3cytgJysIFv0oPevnhCjQZ3ow/qcXSko0K7D blvmmHoozfjic4Y5klVncKcA7Nv/mFxKOSvpKdKUH+zxndcqmNntq4d5OpNFcXxVF6TL gzDHzAKRhbNhicjnx34EzYa6vygS8a99z/6LuB96ArLvrD/SLFYdnle/1SVqPQlC10U8 unHgHvEGDLSG7DR9p6uh4BUWPN86q9sS6v3zqYT2yniDUtDc5oefddKzidJu0u3/oCAh IpZQ== X-Gm-Message-State: AOAM531bGlJTuTmeEHJcv/JOgxoTAmHDhcPgBsqUKvc4PMB7GLwOTbss NgDmR3EQIWBD46171J7tBxfLeg== X-Received: by 2002:a17:90a:d596:: with SMTP id v22mr6926387pju.51.1627711268627; Fri, 30 Jul 2021 23:01:08 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:160:995:7f22:dc59]) by smtp.gmail.com with ESMTPSA id e35sm4090000pjk.28.2021.07.30.23.01.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Jul 2021 23:01:07 -0700 (PDT) Date: Fri, 30 Jul 2021 23:01:02 -0700 From: Fangrui Song To: Nathan Chancellor Cc: Kees Cook , Arnd Bergmann , Nick Desaulniers , Marco Elver , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, clang-built-linux@googlegroups.com, stable@vger.kernel.org Subject: Re: [PATCH v2] vmlinux.lds.h: Handle clang's module.{c,d}tor sections Message-ID: <20210731060102.3p7sknifz4d62ocn@google.com> References: <20210730223815.1382706-1-nathan@kernel.org> <20210731023107.1932981-1-nathan@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20210731023107.1932981-1-nathan@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Reviewed-by: Fangrui Song On 2021-07-30, Nathan Chancellor wrote: >A recent change in LLVM causes module_{c,d}tor sections to appear when >CONFIG_K{A,C}SAN are enabled, which results in orphan section warnings >because these are not handled anywhere: > >ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_ctor) is being placed in '.text.asan.module_ctor' >ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_dtor) is being placed in '.text.asan.module_dtor' >ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.tsan.module_ctor) is being placed in '.text.tsan.module_ctor' > >Fangrui explains: "the function asan.module_ctor has the SHF_GNU_RETAIN >flag, so it is in a separate section even with -fno-function-sections >(default)". If my theory is true, we should see orphan section warning with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION before my sanitizer change. >Place them in the TEXT_TEXT section so that these technologies continue >to work with the newer compiler versions. All of the KASAN and KCSAN >KUnit tests continue to pass after this change. > >Cc: stable@vger.kernel.org >Link: https://github.com/ClangBuiltLinux/linux/issues/1432 >Link: https://github.com/llvm/llvm-project/commit/7b789562244ee941b7bf2cefeb3fc08a59a01865 >Signed-off-by: Nathan Chancellor >--- > >v1 -> v2: > >* Fix inclusion of .text.tsan.* (Nick) > >* Drop .text.asan as it does not exist plus it would be handled by a > different line (Fangrui) > >* Add Fangrui's explanation about why the LLVM commit caused these > sections to appear. > > include/asm-generic/vmlinux.lds.h | 1 + > 1 file changed, 1 insertion(+) > >diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h >index 17325416e2de..62669b36a772 100644 >--- a/include/asm-generic/vmlinux.lds.h >+++ b/include/asm-generic/vmlinux.lds.h >@@ -586,6 +586,7 @@ > NOINSTR_TEXT \ > *(.text..refcount) \ > *(.ref.text) \ >+ *(.text.asan.* .text.tsan.*) \ When kmsan is upstreamed, we may need to add .text.msan.* :) ( I wondered why we cannot just change the TEXT_MAIN pattern to .text.* For large userspace applications, separating .text.unlikely .text.hot can help do things like hugepage and mlock, which can improve instruction cache localize and reduce instruction TLB miss rates,,, but not sure this helps much for the kernel. Or perhaps some .text.FOOBAR has special usage which cannot be placed into the output .text ) > TEXT_CFI_JT \ > MEM_KEEP(init.text*) \ > MEM_KEEP(exit.text*) \ > >base-commit: 4669e13cd67f8532be12815ed3d37e775a9bdc16 >-- >2.32.0.264.g75ae10bc75 >