From: Nick Desaulniers <ndesaulniers@google.com>
To: Josh Poimboeuf <jpoimboe@kernel.org>,
"Borislav Petkov (AMD)" <bp@alien8.de>
Cc: 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 13:29:49 -0700 [thread overview]
Message-ID: <ZDcUvWuqv2VevITe@google.com> (raw)
In-Reply-To: <cb5dab6038dfe5156f5d68424cf372f7eed1b934.1680912057.git.jpoimboe@kernel.org>
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?
For this patch,
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
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)?)
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?
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?
next prev parent reply other threads:[~2023-04-12 20:30 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 [this message]
2023-04-12 21:57 ` Josh Poimboeuf
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=ZDcUvWuqv2VevITe@google.com \
--to=ndesaulniers@google.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=gpiccoli@igalia.com \
--cc=jpoimboe@kernel.org \
--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=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;
as well as URLs for NNTP newsgroup(s).