From: Josh Poimboeuf <jpoimboe@kernel.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: "Borislav Petkov (AMD)" <bp@alien8.de>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Miroslav Benes <mbenes@suse.cz>,
linux-btrfs@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>,
linux-scsi@vger.kernel.org, linux-hyperv@vger.kernel.org,
Arnd Bergmann <arnd@arndb.de>,
"Guilherme G . Piccoli" <gpiccoli@igalia.com>,
Michael Kelley <mikelley@microsoft.com>,
kernel test robot <lkp@intel.com>
Subject: Re: [PATCH 02/11] init: Mark start_kernel() __noreturn
Date: Wed, 12 Apr 2023 14:57:55 -0700 [thread overview]
Message-ID: <20230412215755.bz3nzldqhhc4wjds@treble> (raw)
In-Reply-To: <ZDcUvWuqv2VevITe@google.com>
On Wed, Apr 12, 2023 at 01:29:49PM -0700, Nick Desaulniers wrote:
> On Fri, Apr 07, 2023 at 05:09:55PM -0700, Josh Poimboeuf wrote:
> > Fixes the following warning:
> >
> > vmlinux.o: warning: objtool: x86_64_start_reservations+0x28: unreachable instruction
> >
> > Reported-by: kernel test robot <lkp@intel.com>
> > Link: https://lore.kernel.org/r/202302161142.K3ziREaj-lkp@intel.com/
> > Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
>
> Ah, I just realized that my series will conflict with this.
> https://lore.kernel.org/llvm/20230412-no_stackp-v1-1-46a69b507a4b@google.com/
> Perhaps if my series gets positive feedback; I can rebase it on top of
> this and it can become part of your series?
Sure, I can take these on top.
> For this patch,
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Thanks!
> Though I'm curious, it does look like it's necessary because of 01/11 in
> the series? Any idea how the 0day bot report happened before 1/11
> existed?
>
>
> (Surely gcc isn't assuming a weak function is implicitly noreturn and
> make optimizations based on that (that's one hazard I'm worried about)?)
As far as I can tell, GCC has been doing the right thing here, and it's
instead been objtool getting confused by weak noreturns. That gets
fixed later in patch 9.
> It looks like perhaps the link to
> https://lore.kernel.org/all/202302161142.K3ziREaj-lkp@intel.com/
> on 2/11 was 0day testing the arch-cpu-idle-dead-noreturn branch of your
> kernel tree
> https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=arch-cpu-idle-dead-noreturn
> , which had 1/11 in it, IIUC? Perhaps this link should go on 1/11
> rather than 2/11?
Good catch, patch 1 does introduce the warning. I think I'll just
squash patches 1 and 2 so as not to break bisection.
> Looking back at 1/11, 3/11, 8/11 I noticed not all patches have links to 0day
> reports. Are you able to flesh out more info how/what/when such objtool
> warnings are observed? Are the warnings ever results of patches earlier
> in the series?
Hopefully not, it's best to not introduce warnings even temporarily. I
was doing a lot of build testing at the time with various branches, so
it's possible. I'll see if I can figure out how I triggered those
warnings and document that in the commit logs if possible.
--
Josh
next prev parent reply other threads:[~2023-04-12 21:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-08 0:09 [PATCH 00/12] Sprinkle more __noreturn Josh Poimboeuf
2023-04-08 0:09 ` [PATCH 01/11] init: Mark [arch_call_]rest_init() __noreturn Josh Poimboeuf
2023-04-10 20:02 ` Nick Desaulniers
2023-04-08 0:09 ` [PATCH 02/11] init: Mark start_kernel() __noreturn Josh Poimboeuf
2023-04-12 20:29 ` Nick Desaulniers
2023-04-12 21:57 ` Josh Poimboeuf [this message]
2023-04-12 23:26 ` Josh Poimboeuf
2023-04-08 0:09 ` [PATCH 03/11] x86/head: Mark *_start_kernel() __noreturn Josh Poimboeuf
2023-04-08 0:09 ` [PATCH 04/11] btrfs: Mark btrfs_assertfail() __noreturn Josh Poimboeuf
2023-04-08 0:09 ` [PATCH 05/11] arm64/cpu: Mark cpu_park_loop() and friends __noreturn Josh Poimboeuf
2023-04-08 0:09 ` [PATCH 06/11] cpu: Mark panic_smp_self_stop() __noreturn Josh Poimboeuf
2023-04-08 0:10 ` [PATCH 07/11] cpu: Mark nmi_panic_self_stop() __noreturn Josh Poimboeuf
2023-04-08 0:10 ` [PATCH 08/11] x86/cpu: Mark {hlt,resume}_play_dead() __noreturn Josh Poimboeuf
2023-04-08 0:10 ` [PATCH 09/11] objtool: Include weak functions in global_noreturns check Josh Poimboeuf
2023-04-08 0:10 ` [PATCH 10/11] scsi: message: fusion: Mark mpt_halt_firmware() __noreturn Josh Poimboeuf
2023-04-08 0:10 ` [PATCH 11/11] x86/hyperv: Mark hv_ghcb_terminate() as noreturn Josh Poimboeuf
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=20230412215755.bz3nzldqhhc4wjds@treble \
--to=jpoimboe@kernel.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=gpiccoli@igalia.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lkp@intel.com \
--cc=mark.rutland@arm.com \
--cc=mbenes@suse.cz \
--cc=mikelley@microsoft.com \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox