Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp2157667ybh; Fri, 17 Jul 2020 10:37:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzB4eD5pYhTfZbjBVwEpp8/K6PwFtubrLeHwpKm2mImp0tdCIM6BZnZDR5IUE/BWPzbeMar X-Received: by 2002:a17:906:6d4d:: with SMTP id a13mr9315415ejt.146.1595007452044; Fri, 17 Jul 2020 10:37:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595007452; cv=none; d=google.com; s=arc-20160816; b=Thf+YjH1R9hDLWazbjy6tdm34nNVkXWRX3ZIzmA3ytYG+Rd9a+ohTmkG+KfBZnMYwG MH8QEj1s+2cY1K4dWOyD5NJ0CDSGBAAB9rC7X419Jm2dHtmZEdaL1LucTge9hLezXmJp Mm40ec4L+lA7wYHkcvpl6cvXHOiMnicU4VTOcoVMFbj0VVFQg6nby8KCmUgYmKccxTr9 M4JfqCxG/GIPZ3A70WH6Hazsm17keFFsN1SYo5AaIjAI3ihpuDYteWzAJhoyBMBpMnyN 8GXFW7huoHJgJMuDV2YfVelPL/+qGcnbRU0+OO/54jciz6KojZGfJ1+ymin8i/V/Nb3q E23Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=g+QxGmgT4Y7xEif1US+bUUNoz3x7r8iUBueJvZ4cS8Q=; b=eotcDimzU6tLgEXm8kroZS8xMmfRBt/kfT54o76cd45SYcGHdm9UxsjSlN1IEf6zgd bJGRJyqqrhJjP9kp1KqU7+pnYuoauXos0r+vUYyOoQTfmTRFMHoIsr32uGi9JLYwuCoh h/XUwe7W4lMUDZu1yGs5X0mWjWX3bv+uGYvNgWZGQB+KFIznH7n8PM/EJvfURyiZZXm0 kfToFlm2LJ2ONJT0UDdNmbzgFtcSoYEREMpITcnL4HK5kTLBiUUv/3NiB/BmPUxftbAn fbEprKZJ9S8/UdOS2r0sICXp7QBsVgKNdu2MIXvTz0YxsNzWD/VBviOTTFvYBN1uo+QY IqCA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c17si5788693edr.237.2020.07.17.10.37.09; Fri, 17 Jul 2020 10:37:32 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727916AbgGQRgv (ORCPT + 99 others); Fri, 17 Jul 2020 13:36:51 -0400 Received: from mail.kernel.org ([198.145.29.99]:54978 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726293AbgGQRgv (ORCPT ); Fri, 17 Jul 2020 13:36:51 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5A01420717; Fri, 17 Jul 2020 17:36:48 +0000 (UTC) Date: Fri, 17 Jul 2020 13:36:45 -0400 From: Steven Rostedt To: Sami Tolvanen Cc: Peter Zijlstra , Masahiro Yamada , Will Deacon , 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 , Josh Poimboeuf , Matt Helsley Subject: Re: [RFC][PATCH] objtool,x86_64: Replace recordmcount with objtool Message-ID: <20200717133645.7816c0b6@oasis.local.home> In-Reply-To: References: <20200624203200.78870-1-samitolvanen@google.com> <20200624203200.78870-5-samitolvanen@google.com> <20200624212737.GV4817@hirez.programming.kicks-ass.net> <20200624214530.GA120457@google.com> <20200625074530.GW4817@hirez.programming.kicks-ass.net> <20200625161503.GB173089@google.com> <20200625200235.GQ4781@hirez.programming.kicks-ass.net> <20200625224042.GA169781@google.com> <20200626112931.GF4817@hirez.programming.kicks-ass.net> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 17 Jul 2020 10:28:13 -0700 Sami Tolvanen wrote: > On Fri, Jun 26, 2020 at 4:29 AM Peter Zijlstra wrote: > > > > On Thu, Jun 25, 2020 at 03:40:42PM -0700, Sami Tolvanen wrote: > > > > > > Not boot tested, but it generates the required sections and they look > > > > more or less as expected, ymmv. > > > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > > > index a291823f3f26..189575c12434 100644 > > > > --- a/arch/x86/Kconfig > > > > +++ b/arch/x86/Kconfig > > > > @@ -174,7 +174,6 @@ config X86 > > > > select HAVE_EXIT_THREAD > > > > select HAVE_FAST_GUP > > > > select HAVE_FENTRY if X86_64 || DYNAMIC_FTRACE > > > > - select HAVE_FTRACE_MCOUNT_RECORD > > > > select HAVE_FUNCTION_GRAPH_TRACER > > > > select HAVE_FUNCTION_TRACER > > > > select HAVE_GCC_PLUGINS > > > > > > This breaks DYNAMIC_FTRACE according to kernel/trace/ftrace.c: > > > > > > #ifndef CONFIG_FTRACE_MCOUNT_RECORD > > > # error Dynamic ftrace depends on MCOUNT_RECORD > > > #endif > > > > > > And the build errors after that seem to confirm this. It looks like we might > > > need another flag to skip recordmcount. > > > > Hurm, Steve, how you want to do that? > > Steven, did you have any thoughts about this? Moving recordmcount to > an objtool pass that knows about call sites feels like a much cleaner > solution than annotating kernel code to avoid unwanted relocations. > Bah, I started to reply to this then went to look for details, got distracted, forgot about it, my laptop crashed (due to a zoom call), and I lost the email I was writing (haven't looked in the drafts folder, but my idea about this has changed since anyway). So the problem is that we process mcount references in other areas and that confuses the ftrace modification portion? Someone just submitted a patch for arm64 for this: https://lore.kernel.org/r/20200717143338.19302-1-gregory.herrero@oracle.com Is that what you want? -- Steve