Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 12 Apr 2023 14:57:55 -0700
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
Message-ID: <20230412215755.bz3nzldqhhc4wjds@treble>
References: <cover.1680912057.git.jpoimboe@kernel.org>
 <cb5dab6038dfe5156f5d68424cf372f7eed1b934.1680912057.git.jpoimboe@kernel.org>
 <ZDcUvWuqv2VevITe@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <ZDcUvWuqv2VevITe@google.com>
Precedence: bulk

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