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=-10.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=ham 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 145DCC433E9 for ; Tue, 2 Mar 2021 19:51:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D303864F1D for ; Tue, 2 Mar 2021 19:51:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1835273AbhCBSvt (ORCPT ); Tue, 2 Mar 2021 13:51:49 -0500 Received: from mail.kernel.org ([198.145.29.99]:54866 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1445780AbhCBQHI (ORCPT ); Tue, 2 Mar 2021 11:07:08 -0500 Received: from gandalf.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 19E7961494; Tue, 2 Mar 2021 15:58:29 +0000 (UTC) Date: Tue, 2 Mar 2021 10:58:27 -0500 From: Steven Rostedt To: Peter Zijlstra Cc: Sami Tolvanen , kernel test robot , Kees Cook , LKML , lkp@lists.01.org, kernel test robot Subject: Re: [x86, build] 6dafca9780: WARNING:at_arch/x86/kernel/ftrace.c:#ftrace_verify_code Message-ID: <20210302105827.3403656c@gandalf.local.home> In-Reply-To: References: <20210301074027.GD12822@xsang-OptiPlex-9020> <20210301184524.7aa05ac1@gandalf.local.home> <20210301201526.65ce7f1c@oasis.local.home> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2 Mar 2021 10:19:47 +0100 Peter Zijlstra wrote: > On Mon, Mar 01, 2021 at 08:15:26PM -0500, Steven Rostedt wrote: > > diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c > > index 7edbd5ee5ed4..e8afc765e00a 100644 > > --- a/arch/x86/kernel/ftrace.c > > +++ b/arch/x86/kernel/ftrace.c > > @@ -36,6 +36,7 @@ > > #ifdef CONFIG_DYNAMIC_FTRACE > > > > static int ftrace_poke_late = 0; > > +static const char p6_nop[] = { P6_NOP5 }; > > I don't understand this approach, why not simply rewrite all the nops at > boot and not worry about it when modifying the code later? That was one of the suggestions I made in the first reply. But it's more complex than that. Because the CC_USING_NOP_MCOUNT was added for other architectures (currently only s390 and parisc uses it), it simply skips the process of initializing the mcount/fentry into nops if the compiler had already done it. But because x86 is the only architecture daft enough to have different nops with different "performance" depending on what hardware it's booted on, it's a bit "special". If we have to convert nops at boot up in case the compiler gets it wrong, than why bother having the compiler try in the first place? In other words, the only changes I see is the one I just made, or we rip out CC_USING_NOP_MCOUNT for x86 completely. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============8131287158281002312==" MIME-Version: 1.0 From: Steven Rostedt To: lkp@lists.01.org Subject: Re: [x86, build] 6dafca9780: WARNING:at_arch/x86/kernel/ftrace.c:#ftrace_verify_code Date: Tue, 02 Mar 2021 10:58:27 -0500 Message-ID: <20210302105827.3403656c@gandalf.local.home> In-Reply-To: List-Id: --===============8131287158281002312== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Tue, 2 Mar 2021 10:19:47 +0100 Peter Zijlstra wrote: > On Mon, Mar 01, 2021 at 08:15:26PM -0500, Steven Rostedt wrote: > > diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c > > index 7edbd5ee5ed4..e8afc765e00a 100644 > > --- a/arch/x86/kernel/ftrace.c > > +++ b/arch/x86/kernel/ftrace.c > > @@ -36,6 +36,7 @@ > > #ifdef CONFIG_DYNAMIC_FTRACE > > = > > static int ftrace_poke_late =3D 0; > > +static const char p6_nop[] =3D { P6_NOP5 }; = > = > I don't understand this approach, why not simply rewrite all the nops at > boot and not worry about it when modifying the code later? That was one of the suggestions I made in the first reply. But it's more complex than that. Because the CC_USING_NOP_MCOUNT was added for other architectures (currently only s390 and parisc uses it), it simply skips the process of initializing the mcount/fentry into nops if the compiler had already done it. But because x86 is the only architecture daft enough to have different nops with different "performance" depending on what hardware it's booted on, it's a bit "special". If we have to convert nops at boot up in case the compiler gets it wrong, than why bother having the compiler try in the first place? In other words, the only changes I see is the one I just made, or we rip out CC_USING_NOP_MCOUNT for x86 completely. -- Steve --===============8131287158281002312==--