Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp4731814pxk; Wed, 30 Sep 2020 10:12:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwDhIXMDRNrPnkx98ihz32I+9Iu6qUHz6iZ/Z8Z9SLggHlGkrcIkeBRufWus5o6385dCOIC X-Received: by 2002:a17:906:3791:: with SMTP id n17mr3771516ejc.216.1601485944148; Wed, 30 Sep 2020 10:12:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601485944; cv=none; d=google.com; s=arc-20160816; b=Ju/in0CP0M9kzzIqRoO7BlxN8gzlwoc8/JZmcYGzRnh7egLh+egDc2csoQ+btW+ey1 fwBdbfcy+8vMXI8eqCFw8Y5O4GUQWp4p8Duo3jE3Fkt9yn4AXwrdb9+ltDyXxOwSxxme p+NY8kkFwZZfy8dtaVpDlSjavnnxgz4cwRf0cn52x/WYC1j5hAl+f0d9B8KX6e4Xu8Tg qDLTpY4JVuUzoud5rNR0df+jqfzgHGXt5hT/ztkdUKTTw19VjYr88EySCC3OkOzJuwNt wrIfyWCopAPOMbl6e2/EQBLhBkkCGUuKh2ivOVyvpmWVvQeCSkRhPvRsa9Qwx3GnaTt3 cLEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=BqedzlGX8MsdvOmncyCbTeaSpoiIv6tQfCYOfAGCm1I=; b=OwVMlbDCkkboJVX4QrS9U+iNw6XPBlmqwYWcQCyQD948hCyv7J8vf8geFByTsk1AW1 uUtpgXPcnRtGQI9rWSg7P7daRF+3gGIo5//by2+QXdjPgzXIoDCSiEQPMW5V5mciB263 Gv7kwGv89g0mRu9zQVPOqQPeYrWL1sWxgnDAnfYv12y2Q238Hgg79GeOd2LWjPpwqRcd iqSEuzoXEZ/ZIGvs9pgZHrbhpq4mJBjV6Vhr4E1e1igFmN9xnz987Sndvtni+FgbfZLr XM8feJaya7U+3JEwbC4cg0MjZBkq36nmKOK0ednydaDO3lpRIA31pwpiRydNv0cbdC5/ 0zJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=sE8WZ6lf; 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 c21si1470715edw.18.2020.09.30.10.12.01; Wed, 30 Sep 2020 10:12:24 -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=sE8WZ6lf; 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 S1725815AbgI3RLB (ORCPT + 99 others); Wed, 30 Sep 2020 13:11:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58134 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725385AbgI3RLB (ORCPT ); Wed, 30 Sep 2020 13:11:01 -0400 Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CBF6EC0613D0 for ; Wed, 30 Sep 2020 10:11:00 -0700 (PDT) Received: by mail-ej1-x644.google.com with SMTP id p9so3911232ejf.6 for ; Wed, 30 Sep 2020 10:11:00 -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=BqedzlGX8MsdvOmncyCbTeaSpoiIv6tQfCYOfAGCm1I=; b=sE8WZ6lfb33YbXSwicY08Buxu2+BclRjKlsf3vmfKYC0cOkGjIdkfWlcD3vKlvxBtD oJvOI0Me7W22ashUodxRg8si+zJpy2Cbj36q0/8yWyYhzL0LsEuNIm7mCi4bt0ydDxiP q2wgS9BmhahiQ+5AI274iqgwQFVzecBus9MZf563ErBkJT7H8HSacjGdi407Qm2FFScB UKBxyo4CmvhG4OhR92jBXUX4a8bOh0QyXvaZZAv6dW3JDWi42Xlo+4DGLRhZ05mHElhm akH0k3vLqe2e1OlNqWiJM/8E0bIvbsaLFvn/nLJrGgZiuIkxYeAIludqN2wsfPhdmkyE UahA== 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=BqedzlGX8MsdvOmncyCbTeaSpoiIv6tQfCYOfAGCm1I=; b=tnc4eN38o0PWUGbziD3/lu+YwwVyzc/tBEOEsc+voT1EXgE2wPwijktK70t+s33d1O YUdVJ9suXUEoJ/26x4mbEy7N5i0rubS6trfHfNs4aFSxPteQILO1F0zPPd1d/o+95Mxu bi3uebC7QErKf+urNKvKplzsR4GeZAZajmM5JQi8w13n8JizF9VNCkWakbKoLyxI+k/w SV80sAjTuE2wFaMNaeGU8bYAasdzAmYZN/4e8TuzP5DHR9dvItu+/nZuWbq2GhAgXf+u jG5A75NFoKq4KvOZoV0gA3NVA6npbA7vSdYJfKKYoB4vTXYwPUAA/798NOMvmNCY3V4y ErAQ== X-Gm-Message-State: AOAM532WI4NouzMPptvBS1HaH7NtaejiUwfGcilFDMNud5osYjGsuUe6 hcbtK9vczKppYTPToebIp+d6MI7izPv0HVElWSZrdA== X-Received: by 2002:a17:906:a256:: with SMTP id bi22mr3767975ejb.375.1601485859067; Wed, 30 Sep 2020 10:10:59 -0700 (PDT) MIME-Version: 1.0 References: <20200929214631.3516445-1-samitolvanen@google.com> <20200929214631.3516445-10-samitolvanen@google.com> <20200930095850.GA68612@C02TD0UTHF1T.local> In-Reply-To: <20200930095850.GA68612@C02TD0UTHF1T.local> From: Sami Tolvanen Date: Wed, 30 Sep 2020 10:10:47 -0700 Message-ID: Subject: Re: [PATCH v4 09/29] arm64: disable recordmcount with DYNAMIC_FTRACE_WITH_REGS To: Mark Rutland Cc: Masahiro Yamada , Will Deacon , Steven Rostedt , Peter Zijlstra , Greg Kroah-Hartman , "Paul E. McKenney" , Kees Cook , Nick Desaulniers , clang-built-linux , Kernel Hardening , linux-arch , linux-arm-kernel , linux-kbuild , LKML , linux-pci@vger.kernel.org, X86 ML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mark, On Wed, Sep 30, 2020 at 2:59 AM Mark Rutland wrote: > > Hi Sami, > > On Tue, Sep 29, 2020 at 02:46:11PM -0700, Sami Tolvanen wrote: > > Select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY to disable > > recordmcount when DYNAMIC_FTRACE_WITH_REGS is selected. > > Could you please add an explanation as to /why/ this is necessary in the > commit message? I couldn't figure this out form the commit message > alone, and reading the cover letter also didn't help. Sorry about that, I'll add a better explanation in the next version. Note that without LTO, this change is not strictly necessary as there's no harm in running recordmcount even if it's not needed. It might slow down the build slightly, but I suspect a few thousand invocations of the program won't take that long. However, with LTO we need to disable recordmcount because it doesn't understand LLVM bitcode. > If the minimum required GCC version supports patchable-function-entry > I'd be happy to make that a requirement for dynamic ftrace on arm64, as > then we'd only need to support one mechanism, and can get rid of some > redundant code. We already default to it when present anyhow. That would be great, but Documentation/process/changes.rst suggests the minimum gcc version is 4.9, and according to Godbolt we would need gcc >= 8 for -fpatchable-function-entry: https://godbolt.org/z/jdzcMW > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > > index 6d232837cbee..ad522b021f35 100644 > > --- a/arch/arm64/Kconfig > > +++ b/arch/arm64/Kconfig > > @@ -155,6 +155,8 @@ config ARM64 > > select HAVE_DYNAMIC_FTRACE > > select HAVE_DYNAMIC_FTRACE_WITH_REGS \ > > if $(cc-option,-fpatchable-function-entry=2) > > + select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY \ > > + if DYNAMIC_FTRACE_WITH_REGS > > This doesn't look quite right to me. Presumably we shouldn't allow > DYNAMIC_FTRACE_WITH_REGS to be selected if HAVE_DYNAMIC_FTRACE_WITH_REGS > isn't. This won't allow DYNAMIC_FTRACE_WITH_REGS to be selected without HAVE_DYNAMIC_FTRACE_WITH_REGS. Testing with a compiler that does support -fpatchable-function-entry, I get the following, as expected: $ grep -E '(DYNAMIC_FTRACE|MCOUNT_USE)' .config CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y CONFIG_DYNAMIC_FTRACE=y CONFIG_DYNAMIC_FTRACE_WITH_REGS=y CONFIG_FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY=y And if the compiler doesn't support -fpatchable-function-entry, we would end up with the following: $ grep -E '(DYNAMIC_FTRACE|MCOUNT_USE)' .config CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_DYNAMIC_FTRACE=y CONFIG_FTRACE_MCOUNT_USE_RECORDMCOUNT=y Sami