From: Josh Poimboeuf <jpoimboe@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: kernel test robot <yujie.liu@intel.com>,
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 12:13:53 -0700 [thread overview]
Message-ID: <20220928191353.yu2o7rhkhpi3n74z@treble> (raw)
In-Reply-To: <YzRr23Bn6qFDC7j0@dev-arch.thelio-3990X>
On Wed, Sep 28, 2022 at 08:44:27AM -0700, Nathan Chancellor wrote:
> 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.
Grrr... I really dislike that objtool is capable of bricking the kernel
like this. We just saw something similar in RHEL.
IMO, we should just get rid of this "short JMP" feature in the jump
label code, those saved three bytes aren't worth the pain.
But yes, we do need to fix that config issue.
And yes, maybe fatal objtool warnings should cause a build failure. We
used to do that, but it brought a different sort of pain. But if
objtool is going to be in the kernel's critical boot path then I guess
we have to do that.
--
Josh
WARNING: multiple messages have this Message-ID (diff)
From: Josh Poimboeuf <jpoimboe@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: kernel test robot <yujie.liu@intel.com>,
lkp@intel.com, linux-kbuild@vger.kernel.org, aik@ozlabs.ru,
linuxppc-dev@lists.ozlabs.org, llvm@lists.linux.dev,
linux-kernel@vger.kernel.org, npiggin@gmail.com,
Peter Zijlstra <peterz@infradead.org>,
mingo@redhat.com, Sathvika Vasireddy <sv@linux.ibm.com>,
rostedt@goodmis.org, jpoimboe@redhat.com, lkp@lists.01.org,
mbenes@suse.cz, chenzhongjin@huawei.com,
naveen.n.rao@linux.vnet.ibm.com
Subject: Re: [objtool] ca5e2b42c0: kernel_BUG_at_arch/x86/kernel/jump_label.c
Date: Wed, 28 Sep 2022 12:13:53 -0700 [thread overview]
Message-ID: <20220928191353.yu2o7rhkhpi3n74z@treble> (raw)
In-Reply-To: <YzRr23Bn6qFDC7j0@dev-arch.thelio-3990X>
On Wed, Sep 28, 2022 at 08:44:27AM -0700, Nathan Chancellor wrote:
> 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.
Grrr... I really dislike that objtool is capable of bricking the kernel
like this. We just saw something similar in RHEL.
IMO, we should just get rid of this "short JMP" feature in the jump
label code, those saved three bytes aren't worth the pain.
But yes, we do need to fix that config issue.
And yes, maybe fatal objtool warnings should cause a build failure. We
used to do that, but it brought a different sort of pain. But if
objtool is going to be in the kernel's critical boot path then I guess
we have to do that.
--
Josh
WARNING: multiple messages have this Message-ID (diff)
From: Josh Poimboeuf <jpoimboe@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 12:13:53 -0700 [thread overview]
Message-ID: <20220928191353.yu2o7rhkhpi3n74z@treble> (raw)
In-Reply-To: <YzRr23Bn6qFDC7j0@dev-arch.thelio-3990X>
[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]
On Wed, Sep 28, 2022 at 08:44:27AM -0700, Nathan Chancellor wrote:
> 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.
Grrr... I really dislike that objtool is capable of bricking the kernel
like this. We just saw something similar in RHEL.
IMO, we should just get rid of this "short JMP" feature in the jump
label code, those saved three bytes aren't worth the pain.
But yes, we do need to fix that config issue.
And yes, maybe fatal objtool warnings should cause a build failure. We
used to do that, but it brought a different sort of pain. But if
objtool is going to be in the kernel's critical boot path then I guess
we have to do that.
--
Josh
next prev parent reply other threads:[~2022-09-28 19:13 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
2022-09-28 15:44 ` Nathan Chancellor
2022-09-28 15:44 ` Nathan Chancellor
2022-09-28 19:13 ` Josh Poimboeuf [this message]
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=20220928191353.yu2o7rhkhpi3n74z@treble \
--to=jpoimboe@kernel.org \
--cc=aik@ozlabs.ru \
--cc=chenzhongjin@huawei.com \
--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=nathan@kernel.org \
--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.