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 16:26:54 -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: <20230412232654.vggdl3g5nds64vdd@treble>
References: <cover.1680912057.git.jpoimboe@kernel.org>
 <cb5dab6038dfe5156f5d68424cf372f7eed1b934.1680912057.git.jpoimboe@kernel.org>
 <ZDcUvWuqv2VevITe@google.com>
 <20230412215755.bz3nzldqhhc4wjds@treble>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20230412215755.bz3nzldqhhc4wjds@treble>
Precedence: bulk

On Wed, Apr 12, 2023 at 02:57:57PM -0700, Josh Poimboeuf wrote:
> > 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.

On second thought I won't squash, keeping them separate is useful for
both patches 1 & 2 and patches 5-7.  The patch order goes up the call
stack, i.e. fix callees before callers.  The opposite order would
trigger actual compiler warnings rather than measly objtool warnings :-)

I agree some of the commit logs are indeed confusing and sometimes even
wrong.  I'll clarify the justifications, and remove references to build
bot warnings if they apply to previous patches in the set.

-- 
Josh