From: <kabe@vega.pgw.jp>
To: rostedt@goodmis.org
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
Subject: Re: radeon.ko/i586: BUG: kernel NULL pointer dereference, address:00000004
Date: Sat, 22 Jul 2023 11:30:14 +0900 [thread overview]
Message-ID: <230722113014.M0204460@vega.pgw.jp> (raw)
In-Reply-To: Your message of "Fri, 21 Jul 2023 08:39:55 +0900". <230721083955.M0102626@vega.pgw.jp>
rostedt@goodmis.org sed in <20230717113623.41878887@gandalf.local.home>
>> On Fri, 14 Jul 2023 14:34:04 +0900
>> <kkabe@vega.pgw.jp> 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 <asm/ibt.h>
>> /* 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
WARNING: multiple messages have this Message-ID (diff)
From: <kabe@vega.pgw.jp>
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
Date: Sat, 22 Jul 2023 11:30:14 +0900 [thread overview]
Message-ID: <230722113014.M0204460@vega.pgw.jp> (raw)
In-Reply-To: Your message of "Fri, 21 Jul 2023 08:39:55 +0900". <230721083955.M0102626@vega.pgw.jp>
rostedt@goodmis.org sed in <20230717113623.41878887@gandalf.local.home>
>> On Fri, 14 Jul 2023 14:34:04 +0900
>> <kkabe@vega.pgw.jp> 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 <asm/ibt.h>
>> /* 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
next prev parent reply other threads:[~2023-07-24 12:58 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-14 2:50 Fwd: radeon.ko/i586: BUG: kernel NULL pointer dereference, address: 00000004 Bagas Sanjaya
2023-07-14 2:50 ` Bagas Sanjaya
2023-07-14 3:12 ` Steven Rostedt
2023-07-14 3:12 ` Steven Rostedt
2023-07-14 3:44 ` Linux regression tracking (Thorsten Leemhuis)
2023-07-14 3:44 ` Linux regression tracking (Thorsten Leemhuis)
2023-07-14 5:32 ` radeon.ko/i586: BUG: kernel NULL pointer dereference, address:00000004 kkabe
2023-07-14 5:32 ` kkabe
2023-07-14 5:34 ` kkabe
2023-07-14 5:34 ` kkabe
2023-07-14 14:00 ` Steven Rostedt
2023-07-14 14:00 ` Steven Rostedt
2023-07-15 2:39 ` kkabe
2023-07-15 2:39 ` radeon.ko/i586: BUG: kernel NULL pointer dereference,address:00000004 kkabe
2023-07-17 15:21 ` Steven Rostedt
2023-07-17 15:21 ` Steven Rostedt
2023-07-22 1:57 ` radeon.ko/i586: BUG: kernel NULL pointerdereference, address:00000004 kkabe
2023-07-22 1:57 ` radeon.ko/i586: BUG: kernel NULL pointerdereference,address:00000004 kkabe
2023-07-17 15:36 ` radeon.ko/i586: BUG: kernel NULL pointer dereference, address:00000004 Steven Rostedt
2023-07-17 15:36 ` Steven Rostedt
2023-07-20 23:39 ` kkabe
2023-07-20 23:39 ` radeon.ko/i586: BUG: kernel NULL pointer dereference,address:00000004 kkabe
2023-07-22 2:30 ` kabe [this message]
2023-07-22 2:30 ` kabe
2023-07-23 11:55 ` radeon.ko/i586: BUG: kernel NULL pointer dereference, address:00000004 kkabe
2023-07-23 11:55 ` radeon.ko/i586: BUG: kernel NULL pointer dereference,address:00000004 kkabe
2023-07-23 14:32 ` Steven Rostedt
2023-07-23 14:32 ` Steven Rostedt
2023-08-29 12:08 ` Linux regression tracking (Thorsten Leemhuis)
2023-08-29 12:08 ` Linux regression tracking (Thorsten Leemhuis)
2023-07-23 14:27 ` Steven Rostedt
2023-07-23 14:27 ` Steven Rostedt
2023-10-02 10:03 ` Fwd: radeon.ko/i586: BUG: kernel NULL pointer dereference, address: 00000004 Linux regression tracking #update (Thorsten Leemhuis)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=230722113014.M0204460@vega.pgw.jp \
--to=kabe@vega.pgw.jp \
--cc=Xinhui.Pan@amd.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=bagasdotme@gmail.com \
--cc=bp@alien8.de \
--cc=christian.koenig@amd.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kkabe@vega.pgw.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=regressions@lists.linux.dev \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.