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 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8707AC001DF for ; Mon, 24 Jul 2023 12:58:44 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A342510E30A; Mon, 24 Jul 2023 12:58:43 +0000 (UTC) Received: from mailgw.gate-on.net (auth.Gate-On.Net [210.197.74.21]) by gabe.freedesktop.org (Postfix) with ESMTPS id CC1F610E0D5 for ; Sat, 22 Jul 2023 02:30:20 +0000 (UTC) Received: from vega.pgw.jp (unknown [49.135.109.134]) by mailgw.gate-on.net (Postfix) with ESMTP id 96BCC802A7; Sat, 22 Jul 2023 11:30:18 +0900 (JST) Received: from localhost (vega.pgw.jp [10.5.0.30]) by vega.pgw.jp (Postfix) with SMTP id 265E2A53D; Sat, 22 Jul 2023 11:30:14 +0900 (JST) From: To: rostedt@goodmis.org Subject: Re: radeon.ko/i586: BUG: kernel NULL pointer dereference, address:00000004 In-Reply-To: Your message of "Fri, 21 Jul 2023 08:39:55 +0900". <230721083955.M0102626@vega.pgw.jp> X-Mailer: mnews [version 1.22PL5] 2002-11-27(Wed) Date: Sat, 22 Jul 2023 11:30:14 +0900 Message-ID: <230722113014.M0204460@vega.pgw.jp> X-Mailman-Approved-At: Mon, 24 Jul 2023 12:58:33 +0000 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: dave.hansen@linux.intel.com, regressions@lists.linux.dev, Xinhui.Pan@amd.com, linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org, mingo@redhat.com, bp@alien8.de, bagasdotme@gmail.com, hpa@zytor.com, alexander.deucher@amd.com, tglx@linutronix.de, kkabe@vega.pgw.jp, christian.koenig@amd.com Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" rostedt@goodmis.org sed in <20230717113623.41878887@gandalf.local.home> >> On Fri, 14 Jul 2023 14:34:04 +0900 >> wrote: >> >> > Patch in >> > https://bugzilla.kernel.org/show_bug.cgi?id=217669#c4 >> > fixed the problem in freedesktop.org kernel 5.18.0-rc2 . >> > This may explain that in kernel.org tree, the said commit is in kernel-5.19. >> >> You mean the patch that adds: >> >> #if defined(FTRACE_MCOUNT_MAX_OFFSET) && (FTRACE_MCOUNT_MAX_OFFSET) >> >> ? >> >> Nothing should be setting FTRACE_MCOUNT_MAX_OFFSET to anything but non >> zero. But doing a grep, I now see: >> >> # define FTRACE_MCOUNT_MAX_OFFSET ENDBR_INSN_SIZE >> >> Where it breaks that assumption if ENDBR_INSN_SIZE == 0 :-p >> (and that's my code!) >> >> OK, does this fix it? (I haven't tested nor compiled this) >> >> -- Steve >> >> diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h >> index 897cf02c20b1..801f4414da3e 100644 >> --- a/arch/x86/include/asm/ftrace.h >> +++ b/arch/x86/include/asm/ftrace.h >> @@ -13,7 +13,7 @@ >> #ifdef CONFIG_HAVE_FENTRY >> # include >> /* Add offset for endbr64 if IBT enabled */ >> -# define FTRACE_MCOUNT_MAX_OFFSET ENDBR_INSN_SIZE >> +# define FTRACE_MCOUNT_MAX_OFFSET (ENDBR_INSN_SIZE + MCOUNT_INSN_SIZE) >> #endif >> >> #ifdef CONFIG_DYNAMIC_FTRACE >> Above patch didn't work, but Does it matter that I am compiling with "gcc -fcf-protection=none" to not emit endbr32 instructions for i586? -- kabe From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailgw.gate-on.net (auth.Gate-On.Net [210.197.74.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0CEF9EADC for ; Sat, 22 Jul 2023 02:30:20 +0000 (UTC) Received: from vega.pgw.jp (unknown [49.135.109.134]) by mailgw.gate-on.net (Postfix) with ESMTP id 96BCC802A7; Sat, 22 Jul 2023 11:30:18 +0900 (JST) Received: from localhost (vega.pgw.jp [10.5.0.30]) by vega.pgw.jp (Postfix) with SMTP id 265E2A53D; Sat, 22 Jul 2023 11:30:14 +0900 (JST) From: To: rostedt@goodmis.org Cc: regressions@lists.linux.dev, bagasdotme@gmail.com, alexander.deucher@amd.com, christian.koenig@amd.com, Xinhui.Pan@amd.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org, kkabe@vega.pgw.jp Subject: Re: radeon.ko/i586: BUG: kernel NULL pointer dereference,address:00000004 In-Reply-To: Your message of "Fri, 21 Jul 2023 08:39:55 +0900". <230721083955.M0102626@vega.pgw.jp> X-Mailer: mnews [version 1.22PL5] 2002-11-27(Wed) Date: Sat, 22 Jul 2023 11:30:14 +0900 Message-ID: <230722113014.M0204460@vega.pgw.jp> Precedence: bulk X-Mailing-List: regressions@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: rostedt@goodmis.org sed in <20230717113623.41878887@gandalf.local.home> >> On Fri, 14 Jul 2023 14:34:04 +0900 >> wrote: >> >> > Patch in >> > https://bugzilla.kernel.org/show_bug.cgi?id=217669#c4 >> > fixed the problem in freedesktop.org kernel 5.18.0-rc2 . >> > This may explain that in kernel.org tree, the said commit is in kernel-5.19. >> >> You mean the patch that adds: >> >> #if defined(FTRACE_MCOUNT_MAX_OFFSET) && (FTRACE_MCOUNT_MAX_OFFSET) >> >> ? >> >> Nothing should be setting FTRACE_MCOUNT_MAX_OFFSET to anything but non >> zero. But doing a grep, I now see: >> >> # define FTRACE_MCOUNT_MAX_OFFSET ENDBR_INSN_SIZE >> >> Where it breaks that assumption if ENDBR_INSN_SIZE == 0 :-p >> (and that's my code!) >> >> OK, does this fix it? (I haven't tested nor compiled this) >> >> -- Steve >> >> diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h >> index 897cf02c20b1..801f4414da3e 100644 >> --- a/arch/x86/include/asm/ftrace.h >> +++ b/arch/x86/include/asm/ftrace.h >> @@ -13,7 +13,7 @@ >> #ifdef CONFIG_HAVE_FENTRY >> # include >> /* Add offset for endbr64 if IBT enabled */ >> -# define FTRACE_MCOUNT_MAX_OFFSET ENDBR_INSN_SIZE >> +# define FTRACE_MCOUNT_MAX_OFFSET (ENDBR_INSN_SIZE + MCOUNT_INSN_SIZE) >> #endif >> >> #ifdef CONFIG_DYNAMIC_FTRACE >> Above patch didn't work, but Does it matter that I am compiling with "gcc -fcf-protection=none" to not emit endbr32 instructions for i586? -- kabe