From: Nathan Chancellor <nathan@kernel.org>
To: kernel test robot <yujie.liu@intel.com>
Cc: Sathvika Vasireddy <sv@linux.ibm.com>,
lkp@lists.01.org, lkp@intel.com,
Peter Zijlstra <peterz@infradead.org>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, jpoimboe@redhat.com,
aik@ozlabs.ru, mpe@ellerman.id.au, mingo@redhat.com,
rostedt@goodmis.org, mbenes@suse.cz, npiggin@gmail.com,
chenzhongjin@huawei.com, naveen.n.rao@linux.vnet.ibm.com,
llvm@lists.linux.dev
Subject: Re: [objtool] ca5e2b42c0: kernel_BUG_at_arch/x86/kernel/jump_label.c
Date: Wed, 28 Sep 2022 08:44:27 -0700 [thread overview]
Message-ID: <YzRr23Bn6qFDC7j0@dev-arch.thelio-3990X> (raw)
In-Reply-To: <202209280801.2d5eebb5-yujie.liu@intel.com>
Hi all,
On Wed, Sep 28, 2022 at 08:48:53AM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed the following commit (built with clang-14):
>
> commit: ca5e2b42c0d4438ba93623579b6860b98f3598f3 ("[PATCH v3 11/16] objtool: Add --mnop as an option to --mcount")
> url: https://github.com/intel-lab-lkp/linux/commits/Sathvika-Vasireddy/objtool-Enable-and-implement-mcount-option-on-powerpc/20220912-163023
> base: https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git topic/ppc-kvm
> patch link: https://lore.kernel.org/linuxppc-dev/20220912082020.226755-12-sv@linux.ibm.com
>
> in testcase: boot
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
>
> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
>
> [ 152.068363][ T0] jump_label: Fatal kernel bug, unexpected op at trace_initcall_start+0xc/0x180 [ffffffff810016ec] (e9 c9 00 00 00 != 0f 1f 44 00 00)) size:5 type:1
> [ 152.070368][ T0] ------------[ cut here ]------------
> [ 152.071050][ T0] kernel BUG at arch/x86/kernel/jump_label.c:73!
> [ 152.071825][ T0] invalid opcode: 0000 [#1] SMP KASAN PTI
> [ 152.072427][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.0.0-rc2-00011-gca5e2b42c0d4 #1 96a19ca45386d518c4bccc5b3bc53f548a2dc122
> [ 152.073837][ T0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014
> [ 152.075461][ T0] RIP: 0010:__jump_label_patch+0x340/0x350
> [ 152.076162][ T0] Code: 00 48 89 da e9 51 fe ff ff 48 c7 c7 00 d1 80 83 4c 89 fe 4c 89 fa 4c 89 f9 49 89 d8 45 89 e9 41 54 e8 f2 91 34 02 48 83 c4 08 <0f> 0b 0f 0b 0f 0b 0f 0b 0f 1f 84 00 00 00 00 00 48 c7 c7 00 09 69
> [ 152.078374][ T0] RSP: 0000:ffffffff84607cb8 EFLAGS: 00010086
> [ 152.079159][ T0] RAX: 0000000000000092 RBX: ffffffff8380f62a RCX: ffffffff84634d80
> [ 152.080100][ T0] RDX: 0000000000000000 RSI: 00000000ffffffea RDI: 00000000fffffffe
> [ 152.081020][ T0] RBP: ffffffff855d9f60 R08: ffffffff8124f17c R09: fffffbfff08c0f53
> [ 152.081936][ T0] R10: dffff7fff08c0f54 R11: 1ffffffff08c0f52 R12: 0000000000000001
> [ 152.082832][ T0] R13: 0000000000000005 R14: ffffffff8380f62a R15: ffffffff810016ec
> [ 152.083744][ T0] FS: 0000000000000000(0000) GS:ffff8883aee00000(0000) knlGS:0000000000000000
> [ 152.084763][ T0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 152.085567][ T0] CR2: ffff88843ffff000 CR3: 0000000004628000 CR4: 00000000000406b0
> [ 152.086472][ T0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 152.087407][ T0] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 152.088326][ T0] Call Trace:
> [ 152.088702][ T0] <TASK>
> [ 152.089042][ T0] ? trace_initcall_start+0xc/0x180
> [ 152.089660][ T0] ? trace_initcall_start+0x1b/0x180
> [ 152.090281][ T0] ? trace_initcall_start+0x11/0x180
> [ 152.091237][ T0] ? jump_label_transform+0x25/0xd0
> [ 152.091923][ T0] ? arch_jump_label_transform_queue+0x87/0xd0
> [ 152.092651][ T0] ? __jump_label_update+0x192/0x3b0
> [ 152.093320][ T0] ? static_key_enable_cpuslocked+0x129/0x250
> [ 152.094020][ T0] ? rcu_lock_release+0x20/0x20
> [ 152.094573][ T0] ? static_key_enable+0x16/0x20
> [ 152.095167][ T0] ? tracepoint_add_func+0x87e/0x9d0
> [ 152.095822][ T0] ? rcu_lock_release+0x20/0x20
> [ 152.096394][ T0] ? tracepoint_probe_register+0x99/0xd0
> [ 152.097055][ T0] ? rcu_lock_release+0x20/0x20
> [ 152.097606][ T0] ? initcall_debug_enable+0x21/0x6b
> [ 152.098305][ T0] ? start_kernel+0x24b/0x4e6
> [ 152.098861][ T0] ? secondary_startup_64_no_verify+0xce/0xdb
> [ 152.099556][ T0] </TASK>
> [ 152.099891][ T0] Modules linked in:
> [ 152.100352][ T0] ---[ end trace 0000000000000000 ]---
> [ 152.100980][ T0] RIP: 0010:__jump_label_patch+0x340/0x350
> [ 152.101652][ T0] Code: 00 48 89 da e9 51 fe ff ff 48 c7 c7 00 d1 80 83 4c 89 fe 4c 89 fa 4c 89 f9 49 89 d8 45 89 e9 41 54 e8 f2 91 34 02 48 83 c4 08 <0f> 0b 0f 0b 0f 0b 0f 0b 0f 1f 84 00 00 00 00 00 48 c7 c7 00 09 69
> [ 152.103892][ T0] RSP: 0000:ffffffff84607cb8 EFLAGS: 00010086
> [ 152.104544][ T0] RAX: 0000000000000092 RBX: ffffffff8380f62a RCX: ffffffff84634d80
> [ 152.105421][ T0] RDX: 0000000000000000 RSI: 00000000ffffffea RDI: 00000000fffffffe
> [ 152.106280][ T0] RBP: ffffffff855d9f60 R08: ffffffff8124f17c R09: fffffbfff08c0f53
> [ 152.107182][ T0] R10: dffff7fff08c0f54 R11: 1ffffffff08c0f52 R12: 0000000000000001
> [ 152.108110][ T0] R13: 0000000000000005 R14: ffffffff8380f62a R15: ffffffff810016ec
> [ 152.109002][ T0] FS: 0000000000000000(0000) GS:ffff8883aee00000(0000) knlGS:0000000000000000
> [ 152.109986][ T0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 152.110796][ T0] CR2: ffff88843ffff000 CR3: 0000000004628000 CR4: 00000000000406b0
> [ 152.111748][ T0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 152.112686][ T0] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 152.113568][ T0] Kernel panic - not syncing: Fatal exception
>
>
> If you fix the issue, kindly add following tag
> | Reported-by: kernel test robot <yujie.liu@intel.com>
> | Link: https://lore.kernel.org/r/202209280801.2d5eebb5-yujie.liu@intel.com
This crash appears to just be a symptom of objtool erroring throughout
the entire build, which means things like the jump label hacks do not
get applied. I see a flood of
error: objtool: --mnop requires --mcount
throughout the build because the configuration has
CONFIG_HAVE_NOP_MCOUNT=y because CONFIG_HAVE_OBJTOOL_MCOUNT is
unconditionally enabled for x86_64 due to CONFIG_HAVE_OBJTOOL but
'--mcount' is only actually used when CONFIG_FTRACE_MCOUNT_USE_OBJTOOL
is enabled so '--mnop' gets passed in without '--mcount'. This should
obviously be fixed somehow, perhaps by moving the '--mnop' addition into
the '--mcount' if, even if that makes the line really long.
A secondary issue is that it seems like if objtool encounters a fatal
error like this, it should completely fail the build to make it obvious
that something is wrong, rather than allowing it to continue and
generate a broken kernel, especially since x86_64 requires objtool to
build a working kernel at this point.
Cheers,
Nathan
WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <nathan@kernel.org>
To: kernel test robot <yujie.liu@intel.com>
Cc: lkp@intel.com, aik@ozlabs.ru, linux-kbuild@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
chenzhongjin@huawei.com, llvm@lists.linux.dev, npiggin@gmail.com,
linux-kernel@vger.kernel.org, lkp@lists.01.org, mingo@redhat.com,
Sathvika Vasireddy <sv@linux.ibm.com>,
rostedt@goodmis.org, jpoimboe@redhat.com,
naveen.n.rao@linux.vnet.ibm.com, mbenes@suse.cz,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [objtool] ca5e2b42c0: kernel_BUG_at_arch/x86/kernel/jump_label.c
Date: Wed, 28 Sep 2022 08:44:27 -0700 [thread overview]
Message-ID: <YzRr23Bn6qFDC7j0@dev-arch.thelio-3990X> (raw)
In-Reply-To: <202209280801.2d5eebb5-yujie.liu@intel.com>
Hi all,
On Wed, Sep 28, 2022 at 08:48:53AM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed the following commit (built with clang-14):
>
> commit: ca5e2b42c0d4438ba93623579b6860b98f3598f3 ("[PATCH v3 11/16] objtool: Add --mnop as an option to --mcount")
> url: https://github.com/intel-lab-lkp/linux/commits/Sathvika-Vasireddy/objtool-Enable-and-implement-mcount-option-on-powerpc/20220912-163023
> base: https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git topic/ppc-kvm
> patch link: https://lore.kernel.org/linuxppc-dev/20220912082020.226755-12-sv@linux.ibm.com
>
> in testcase: boot
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
>
> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
>
> [ 152.068363][ T0] jump_label: Fatal kernel bug, unexpected op at trace_initcall_start+0xc/0x180 [ffffffff810016ec] (e9 c9 00 00 00 != 0f 1f 44 00 00)) size:5 type:1
> [ 152.070368][ T0] ------------[ cut here ]------------
> [ 152.071050][ T0] kernel BUG at arch/x86/kernel/jump_label.c:73!
> [ 152.071825][ T0] invalid opcode: 0000 [#1] SMP KASAN PTI
> [ 152.072427][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.0.0-rc2-00011-gca5e2b42c0d4 #1 96a19ca45386d518c4bccc5b3bc53f548a2dc122
> [ 152.073837][ T0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014
> [ 152.075461][ T0] RIP: 0010:__jump_label_patch+0x340/0x350
> [ 152.076162][ T0] Code: 00 48 89 da e9 51 fe ff ff 48 c7 c7 00 d1 80 83 4c 89 fe 4c 89 fa 4c 89 f9 49 89 d8 45 89 e9 41 54 e8 f2 91 34 02 48 83 c4 08 <0f> 0b 0f 0b 0f 0b 0f 0b 0f 1f 84 00 00 00 00 00 48 c7 c7 00 09 69
> [ 152.078374][ T0] RSP: 0000:ffffffff84607cb8 EFLAGS: 00010086
> [ 152.079159][ T0] RAX: 0000000000000092 RBX: ffffffff8380f62a RCX: ffffffff84634d80
> [ 152.080100][ T0] RDX: 0000000000000000 RSI: 00000000ffffffea RDI: 00000000fffffffe
> [ 152.081020][ T0] RBP: ffffffff855d9f60 R08: ffffffff8124f17c R09: fffffbfff08c0f53
> [ 152.081936][ T0] R10: dffff7fff08c0f54 R11: 1ffffffff08c0f52 R12: 0000000000000001
> [ 152.082832][ T0] R13: 0000000000000005 R14: ffffffff8380f62a R15: ffffffff810016ec
> [ 152.083744][ T0] FS: 0000000000000000(0000) GS:ffff8883aee00000(0000) knlGS:0000000000000000
> [ 152.084763][ T0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 152.085567][ T0] CR2: ffff88843ffff000 CR3: 0000000004628000 CR4: 00000000000406b0
> [ 152.086472][ T0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 152.087407][ T0] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 152.088326][ T0] Call Trace:
> [ 152.088702][ T0] <TASK>
> [ 152.089042][ T0] ? trace_initcall_start+0xc/0x180
> [ 152.089660][ T0] ? trace_initcall_start+0x1b/0x180
> [ 152.090281][ T0] ? trace_initcall_start+0x11/0x180
> [ 152.091237][ T0] ? jump_label_transform+0x25/0xd0
> [ 152.091923][ T0] ? arch_jump_label_transform_queue+0x87/0xd0
> [ 152.092651][ T0] ? __jump_label_update+0x192/0x3b0
> [ 152.093320][ T0] ? static_key_enable_cpuslocked+0x129/0x250
> [ 152.094020][ T0] ? rcu_lock_release+0x20/0x20
> [ 152.094573][ T0] ? static_key_enable+0x16/0x20
> [ 152.095167][ T0] ? tracepoint_add_func+0x87e/0x9d0
> [ 152.095822][ T0] ? rcu_lock_release+0x20/0x20
> [ 152.096394][ T0] ? tracepoint_probe_register+0x99/0xd0
> [ 152.097055][ T0] ? rcu_lock_release+0x20/0x20
> [ 152.097606][ T0] ? initcall_debug_enable+0x21/0x6b
> [ 152.098305][ T0] ? start_kernel+0x24b/0x4e6
> [ 152.098861][ T0] ? secondary_startup_64_no_verify+0xce/0xdb
> [ 152.099556][ T0] </TASK>
> [ 152.099891][ T0] Modules linked in:
> [ 152.100352][ T0] ---[ end trace 0000000000000000 ]---
> [ 152.100980][ T0] RIP: 0010:__jump_label_patch+0x340/0x350
> [ 152.101652][ T0] Code: 00 48 89 da e9 51 fe ff ff 48 c7 c7 00 d1 80 83 4c 89 fe 4c 89 fa 4c 89 f9 49 89 d8 45 89 e9 41 54 e8 f2 91 34 02 48 83 c4 08 <0f> 0b 0f 0b 0f 0b 0f 0b 0f 1f 84 00 00 00 00 00 48 c7 c7 00 09 69
> [ 152.103892][ T0] RSP: 0000:ffffffff84607cb8 EFLAGS: 00010086
> [ 152.104544][ T0] RAX: 0000000000000092 RBX: ffffffff8380f62a RCX: ffffffff84634d80
> [ 152.105421][ T0] RDX: 0000000000000000 RSI: 00000000ffffffea RDI: 00000000fffffffe
> [ 152.106280][ T0] RBP: ffffffff855d9f60 R08: ffffffff8124f17c R09: fffffbfff08c0f53
> [ 152.107182][ T0] R10: dffff7fff08c0f54 R11: 1ffffffff08c0f52 R12: 0000000000000001
> [ 152.108110][ T0] R13: 0000000000000005 R14: ffffffff8380f62a R15: ffffffff810016ec
> [ 152.109002][ T0] FS: 0000000000000000(0000) GS:ffff8883aee00000(0000) knlGS:0000000000000000
> [ 152.109986][ T0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 152.110796][ T0] CR2: ffff88843ffff000 CR3: 0000000004628000 CR4: 00000000000406b0
> [ 152.111748][ T0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 152.112686][ T0] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 152.113568][ T0] Kernel panic - not syncing: Fatal exception
>
>
> If you fix the issue, kindly add following tag
> | Reported-by: kernel test robot <yujie.liu@intel.com>
> | Link: https://lore.kernel.org/r/202209280801.2d5eebb5-yujie.liu@intel.com
This crash appears to just be a symptom of objtool erroring throughout
the entire build, which means things like the jump label hacks do not
get applied. I see a flood of
error: objtool: --mnop requires --mcount
throughout the build because the configuration has
CONFIG_HAVE_NOP_MCOUNT=y because CONFIG_HAVE_OBJTOOL_MCOUNT is
unconditionally enabled for x86_64 due to CONFIG_HAVE_OBJTOOL but
'--mcount' is only actually used when CONFIG_FTRACE_MCOUNT_USE_OBJTOOL
is enabled so '--mnop' gets passed in without '--mcount'. This should
obviously be fixed somehow, perhaps by moving the '--mnop' addition into
the '--mcount' if, even if that makes the line really long.
A secondary issue is that it seems like if objtool encounters a fatal
error like this, it should completely fail the build to make it obvious
that something is wrong, rather than allowing it to continue and
generate a broken kernel, especially since x86_64 requires objtool to
build a working kernel at this point.
Cheers,
Nathan
WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <nathan@kernel.org>
To: lkp@lists.01.org
Subject: Re: [objtool] ca5e2b42c0: kernel_BUG_at_arch/x86/kernel/jump_label.c
Date: Wed, 28 Sep 2022 08:44:27 -0700 [thread overview]
Message-ID: <YzRr23Bn6qFDC7j0@dev-arch.thelio-3990X> (raw)
In-Reply-To: <202209280801.2d5eebb5-yujie.liu@intel.com>
[-- Attachment #1: Type: text/plain, Size: 6497 bytes --]
Hi all,
On Wed, Sep 28, 2022 at 08:48:53AM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed the following commit (built with clang-14):
>
> commit: ca5e2b42c0d4438ba93623579b6860b98f3598f3 ("[PATCH v3 11/16] objtool: Add --mnop as an option to --mcount")
> url: https://github.com/intel-lab-lkp/linux/commits/Sathvika-Vasireddy/objtool-Enable-and-implement-mcount-option-on-powerpc/20220912-163023
> base: https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git topic/ppc-kvm
> patch link: https://lore.kernel.org/linuxppc-dev/20220912082020.226755-12-sv(a)linux.ibm.com
>
> in testcase: boot
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
>
> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
>
> [ 152.068363][ T0] jump_label: Fatal kernel bug, unexpected op at trace_initcall_start+0xc/0x180 [ffffffff810016ec] (e9 c9 00 00 00 != 0f 1f 44 00 00)) size:5 type:1
> [ 152.070368][ T0] ------------[ cut here ]------------
> [ 152.071050][ T0] kernel BUG at arch/x86/kernel/jump_label.c:73!
> [ 152.071825][ T0] invalid opcode: 0000 [#1] SMP KASAN PTI
> [ 152.072427][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.0.0-rc2-00011-gca5e2b42c0d4 #1 96a19ca45386d518c4bccc5b3bc53f548a2dc122
> [ 152.073837][ T0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014
> [ 152.075461][ T0] RIP: 0010:__jump_label_patch+0x340/0x350
> [ 152.076162][ T0] Code: 00 48 89 da e9 51 fe ff ff 48 c7 c7 00 d1 80 83 4c 89 fe 4c 89 fa 4c 89 f9 49 89 d8 45 89 e9 41 54 e8 f2 91 34 02 48 83 c4 08 <0f> 0b 0f 0b 0f 0b 0f 0b 0f 1f 84 00 00 00 00 00 48 c7 c7 00 09 69
> [ 152.078374][ T0] RSP: 0000:ffffffff84607cb8 EFLAGS: 00010086
> [ 152.079159][ T0] RAX: 0000000000000092 RBX: ffffffff8380f62a RCX: ffffffff84634d80
> [ 152.080100][ T0] RDX: 0000000000000000 RSI: 00000000ffffffea RDI: 00000000fffffffe
> [ 152.081020][ T0] RBP: ffffffff855d9f60 R08: ffffffff8124f17c R09: fffffbfff08c0f53
> [ 152.081936][ T0] R10: dffff7fff08c0f54 R11: 1ffffffff08c0f52 R12: 0000000000000001
> [ 152.082832][ T0] R13: 0000000000000005 R14: ffffffff8380f62a R15: ffffffff810016ec
> [ 152.083744][ T0] FS: 0000000000000000(0000) GS:ffff8883aee00000(0000) knlGS:0000000000000000
> [ 152.084763][ T0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 152.085567][ T0] CR2: ffff88843ffff000 CR3: 0000000004628000 CR4: 00000000000406b0
> [ 152.086472][ T0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 152.087407][ T0] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 152.088326][ T0] Call Trace:
> [ 152.088702][ T0] <TASK>
> [ 152.089042][ T0] ? trace_initcall_start+0xc/0x180
> [ 152.089660][ T0] ? trace_initcall_start+0x1b/0x180
> [ 152.090281][ T0] ? trace_initcall_start+0x11/0x180
> [ 152.091237][ T0] ? jump_label_transform+0x25/0xd0
> [ 152.091923][ T0] ? arch_jump_label_transform_queue+0x87/0xd0
> [ 152.092651][ T0] ? __jump_label_update+0x192/0x3b0
> [ 152.093320][ T0] ? static_key_enable_cpuslocked+0x129/0x250
> [ 152.094020][ T0] ? rcu_lock_release+0x20/0x20
> [ 152.094573][ T0] ? static_key_enable+0x16/0x20
> [ 152.095167][ T0] ? tracepoint_add_func+0x87e/0x9d0
> [ 152.095822][ T0] ? rcu_lock_release+0x20/0x20
> [ 152.096394][ T0] ? tracepoint_probe_register+0x99/0xd0
> [ 152.097055][ T0] ? rcu_lock_release+0x20/0x20
> [ 152.097606][ T0] ? initcall_debug_enable+0x21/0x6b
> [ 152.098305][ T0] ? start_kernel+0x24b/0x4e6
> [ 152.098861][ T0] ? secondary_startup_64_no_verify+0xce/0xdb
> [ 152.099556][ T0] </TASK>
> [ 152.099891][ T0] Modules linked in:
> [ 152.100352][ T0] ---[ end trace 0000000000000000 ]---
> [ 152.100980][ T0] RIP: 0010:__jump_label_patch+0x340/0x350
> [ 152.101652][ T0] Code: 00 48 89 da e9 51 fe ff ff 48 c7 c7 00 d1 80 83 4c 89 fe 4c 89 fa 4c 89 f9 49 89 d8 45 89 e9 41 54 e8 f2 91 34 02 48 83 c4 08 <0f> 0b 0f 0b 0f 0b 0f 0b 0f 1f 84 00 00 00 00 00 48 c7 c7 00 09 69
> [ 152.103892][ T0] RSP: 0000:ffffffff84607cb8 EFLAGS: 00010086
> [ 152.104544][ T0] RAX: 0000000000000092 RBX: ffffffff8380f62a RCX: ffffffff84634d80
> [ 152.105421][ T0] RDX: 0000000000000000 RSI: 00000000ffffffea RDI: 00000000fffffffe
> [ 152.106280][ T0] RBP: ffffffff855d9f60 R08: ffffffff8124f17c R09: fffffbfff08c0f53
> [ 152.107182][ T0] R10: dffff7fff08c0f54 R11: 1ffffffff08c0f52 R12: 0000000000000001
> [ 152.108110][ T0] R13: 0000000000000005 R14: ffffffff8380f62a R15: ffffffff810016ec
> [ 152.109002][ T0] FS: 0000000000000000(0000) GS:ffff8883aee00000(0000) knlGS:0000000000000000
> [ 152.109986][ T0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 152.110796][ T0] CR2: ffff88843ffff000 CR3: 0000000004628000 CR4: 00000000000406b0
> [ 152.111748][ T0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 152.112686][ T0] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 152.113568][ T0] Kernel panic - not syncing: Fatal exception
>
>
> If you fix the issue, kindly add following tag
> | Reported-by: kernel test robot <yujie.liu@intel.com>
> | Link: https://lore.kernel.org/r/202209280801.2d5eebb5-yujie.liu(a)intel.com
This crash appears to just be a symptom of objtool erroring throughout
the entire build, which means things like the jump label hacks do not
get applied. I see a flood of
error: objtool: --mnop requires --mcount
throughout the build because the configuration has
CONFIG_HAVE_NOP_MCOUNT=y because CONFIG_HAVE_OBJTOOL_MCOUNT is
unconditionally enabled for x86_64 due to CONFIG_HAVE_OBJTOOL but
'--mcount' is only actually used when CONFIG_FTRACE_MCOUNT_USE_OBJTOOL
is enabled so '--mnop' gets passed in without '--mcount'. This should
obviously be fixed somehow, perhaps by moving the '--mnop' addition into
the '--mcount' if, even if that makes the line really long.
A secondary issue is that it seems like if objtool encounters a fatal
error like this, it should completely fail the build to make it obvious
that something is wrong, rather than allowing it to continue and
generate a broken kernel, especially since x86_64 requires objtool to
build a working kernel at this point.
Cheers,
Nathan
next prev parent reply other threads:[~2022-09-28 15:44 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-12 8:20 [PATCH v3 00/16] objtool: Enable and implement --mcount option on powerpc Sathvika Vasireddy
2022-09-12 8:20 ` Sathvika Vasireddy
2022-09-12 8:20 ` [PATCH v3 01/16] powerpc: Fix __WARN_FLAGS() for use with Objtool Sathvika Vasireddy
2022-09-12 8:20 ` Sathvika Vasireddy
2022-09-12 8:20 ` [PATCH v3 02/16] powerpc: Override __ALIGN and __ALIGN_STR macros Sathvika Vasireddy
2022-09-12 8:20 ` Sathvika Vasireddy
2022-09-13 12:03 ` Peter Zijlstra
2022-09-13 12:03 ` Peter Zijlstra
2022-09-13 12:21 ` Christophe Leroy
2022-09-13 12:21 ` Christophe Leroy
2022-09-13 13:15 ` Peter Zijlstra
2022-09-13 13:15 ` Peter Zijlstra
2022-09-12 8:20 ` [PATCH v3 03/16] powerpc: Fix objtool unannotated intra-function call warnings Sathvika Vasireddy
2022-09-12 8:20 ` Sathvika Vasireddy
2022-09-12 8:20 ` [PATCH v3 04/16] powerpc: Curb objtool unannotated intra-function warnings Sathvika Vasireddy
2022-09-12 8:20 ` Sathvika Vasireddy
2022-09-12 8:20 ` [PATCH v3 05/16] powerpc: Skip objtool from running on drivers/crypto/vmx/aesp8-ppc.o Sathvika Vasireddy
2022-09-12 8:20 ` Sathvika Vasireddy
2022-09-12 8:20 ` [PATCH v3 06/16] powerpc: Fix objtool unannotated intra-function call warnings on PPC32 Sathvika Vasireddy
2022-09-12 8:20 ` Sathvika Vasireddy
2022-09-12 8:20 ` [PATCH v3 07/16] powerpc: Skip objtool from running on VDSO files Sathvika Vasireddy
2022-09-12 8:20 ` Sathvika Vasireddy
2022-09-12 8:20 ` [PATCH v3 08/16] objtool: Fix SEGFAULT Sathvika Vasireddy
2022-09-12 8:20 ` Sathvika Vasireddy
2022-09-12 8:20 ` [PATCH v3 09/16] objtool: Use target file endianness instead of a compiled constant Sathvika Vasireddy
2022-09-12 8:20 ` Sathvika Vasireddy
2022-09-12 8:20 ` [PATCH v3 10/16] objtool: Use target file class size " Sathvika Vasireddy
2022-09-12 8:20 ` Sathvika Vasireddy
2022-09-12 8:20 ` [PATCH v3 11/16] objtool: Add --mnop as an option to --mcount Sathvika Vasireddy
2022-09-12 8:20 ` Sathvika Vasireddy
2022-09-12 18:55 ` kernel test robot
2022-09-12 18:55 ` kernel test robot
2022-09-15 6:56 ` Naveen N. Rao
2022-09-15 6:56 ` Naveen N. Rao
2022-09-15 6:56 ` Naveen N. Rao
2022-09-17 19:12 ` kernel test robot
2022-09-17 19:12 ` kernel test robot
2022-09-28 0:48 ` [objtool] ca5e2b42c0: kernel_BUG_at_arch/x86/kernel/jump_label.c kernel test robot
2022-09-28 0:48 ` kernel test robot
2022-09-28 0:48 ` kernel test robot
2022-09-28 15:44 ` Nathan Chancellor [this message]
2022-09-28 15:44 ` Nathan Chancellor
2022-09-28 15:44 ` Nathan Chancellor
2022-09-28 19:13 ` Josh Poimboeuf
2022-09-28 19:13 ` Josh Poimboeuf
2022-09-28 19:13 ` Josh Poimboeuf
2022-09-28 20:45 ` Nathan Chancellor
2022-09-28 20:45 ` Nathan Chancellor
2022-09-28 20:45 ` Nathan Chancellor
2022-09-12 8:20 ` [PATCH v3 12/16] objtool: Read special sections with alts only when specific options are selected Sathvika Vasireddy
2022-09-12 8:20 ` Sathvika Vasireddy
2022-09-12 8:20 ` [PATCH v3 13/16] objtool: Use macros to define arch specific reloc types Sathvika Vasireddy
2022-09-12 8:20 ` Sathvika Vasireddy
2022-09-12 8:20 ` [PATCH v3 14/16] objtool: Add arch specific function arch_ftrace_match() Sathvika Vasireddy
2022-09-12 8:20 ` Sathvika Vasireddy
2022-09-12 8:20 ` [PATCH v3 15/16] objtool/powerpc: Enable objtool to be built on ppc Sathvika Vasireddy
2022-09-12 8:20 ` Sathvika Vasireddy
2022-09-12 8:20 ` [PATCH v3 16/16] objtool/powerpc: Add --mcount specific implementation Sathvika Vasireddy
2022-09-12 8:20 ` Sathvika Vasireddy
2022-09-13 10:00 ` Christophe Leroy
2022-09-13 10:00 ` Christophe Leroy
2022-09-13 14:13 ` [PATCH v3 00/16] objtool: Enable and implement --mcount option on powerpc Peter Zijlstra
2022-09-13 14:13 ` Peter Zijlstra
2022-09-14 0:15 ` Josh Poimboeuf
2022-09-14 0:15 ` Josh Poimboeuf
2022-09-21 9:10 ` Sathvika Vasireddy
2022-09-21 9:10 ` Sathvika Vasireddy
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=YzRr23Bn6qFDC7j0@dev-arch.thelio-3990X \
--to=nathan@kernel.org \
--cc=aik@ozlabs.ru \
--cc=chenzhongjin@huawei.com \
--cc=christophe.leroy@csgroup.eu \
--cc=jpoimboe@redhat.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lkp@intel.com \
--cc=lkp@lists.01.org \
--cc=llvm@lists.linux.dev \
--cc=mbenes@suse.cz \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=naveen.n.rao@linux.vnet.ibm.com \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sv@linux.ibm.com \
--cc=yujie.liu@intel.com \
/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.