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=-8.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=unavailable 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 52C33C433DF for ; Wed, 22 Jul 2020 17:57:13 +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 19C4B208E4 for ; Wed, 22 Jul 2020 17:57:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="L6yw9aD0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 19C4B208E4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org 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:MIME-Version:References:In-Reply-To:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=mmGN8VJbOUONeANL+N1FoF4jZfA1RW2WLEWErrxYpUg=; b=L6yw9aD0cij+cvRjjiRcN6oZe 0CjOdR99OheOL9VBfzcOrCaNOmZNPkBeIxjc9pTDWUNWyswjCPpa8AOKDerIedoNTy+oVV9/7UJer GYK5qEuhYJi8cd9+GFJyuOp+v+QEn2l+y9tjVElIip0uNafdnQmaKT6H/v3YfrzyyEYL9yGl5HNU1 gLoVdvetzJic84G6bcG/UhRgL5uB4JeZPe7i86UsOEzWj3fNwADWbw1ANwSibF6qf/3JRl9JbW8MI /6AYLdEVMrRn2fCn4QUnOVBMgEp96xUB9Smyw5SiLOtzjwQSD8B9lM7+4+8smMprLf4QyA29j60WQ FdPVMn3pw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jyIy5-0004gW-MM; Wed, 22 Jul 2020 17:55:49 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jyIy3-0004fG-8w for linux-arm-kernel@lists.infradead.org; Wed, 22 Jul 2020 17:55:48 +0000 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 F362F20787; Wed, 22 Jul 2020 17:55:43 +0000 (UTC) Date: Wed, 22 Jul 2020 13:55:42 -0400 From: Steven Rostedt To: Peter Zijlstra Subject: Re: [RFC][PATCH] objtool,x86_64: Replace recordmcount with objtool Message-ID: <20200722135542.41127cc4@oasis.local.home> In-Reply-To: <20200626112931.GF4817@hirez.programming.kicks-ass.net> 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200722_135547_485576_72862145 X-CRM114-Status: GOOD ( 26.81 ) 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@vger.kernel.org, x86@kernel.org, Kees Cook , "Paul E. McKenney" , kernel-hardening@lists.openwall.com, Greg Kroah-Hartman , Masahiro Yamada , linux-kbuild@vger.kernel.org, Nick Desaulniers , linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com, Josh Poimboeuf , Sami Tolvanen , linux-pci@vger.kernel.org, Will Deacon , linux-arm-kernel@lists.infradead.org, mhelsley@vmware.com 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 Fri, 26 Jun 2020 13:29:31 +0200 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? That was added when we removed that dangerous daemon that did the updates, and was added to make sure it didn't come back. We can probably just get rid of it. > > > Anyway, since objtool is run before recordmcount, I just left this unchanged > > for testing and ignored the recordmcount warnings about __mcount_loc already > > existing. Something is a bit off still though, I see this at boot: > > > > ------------[ ftrace bug ]------------ > > ftrace failed to modify > > [] __tracepoint_iter_initcall_level+0x0/0x40 > > actual: 0f:1f:44:00:00 > > Initializing ftrace call sites > > ftrace record flags: 0 > > (0) > > expected tramp: ffffffff81056500 > > ------------[ cut here ]------------ > > > > Otherwise, this looks pretty good. > > Ha! it is trying to convert the "CALL __fentry__" into a NOP and not > finding the CALL -- because objtool already made it a NOP... > > Weird, I thought recordmcount would also write NOPs, it certainly has > code for that. I suppose we can use CC_USING_NOP_MCOUNT to avoid those, > but I'd rather Steve explain this before I wreck things further. The reason for not having recordmcount insert all the nops, is because x86 has more than one optimal nop which is determined by the machine it runs on, and not at compile time. So we figured just updated it then. We can change it to be a nop on boot, and just modify it if it's not the optimal nop already. That said, Andi Kleen added an option to gcc called -mnop-mcount which will have gcc do both create the mcount section and convert the calls into nops. When doing so, it defines CC_USING_NOP_MCOUNT which will tell ftrace to expect the calls to already be converted. -- Steve _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel