Date:   Mon, 30 May 2022 21:37:19 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Russell King <rmk+kernel@...linux.org.uk>,
        Sasha Levin <sashal@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "# 3.4.x" <stable@...r.kernel.org>,
        Russell King <linux@...linux.org.uk>,
        Linus Walleij <linus.walleij@...aro.org>,
        Nicolas Pitre <nico@...xnic.net>,
        Keith Packard <keithpac@...zon.com>,
        Arnd Bergmann <arnd@...db.de>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH AUTOSEL 5.18 147/159] ARM: 9201/1: spectre-bhb: rely on
 linker to emit cross-section literal loads

On Mon, May 30, 2022 at 05:56:09PM +0200, Ard Biesheuvel wrote:
> On Mon, 30 May 2022 at 17:25, Greg KH <gregkh@...uxfoundation.org> wrote:
> >
> > On Mon, May 30, 2022 at 03:32:47PM +0200, Ard Biesheuvel wrote:
> > > AUTONAK
> > >
> > > As discussed before, please disregard all patches authored by me when
> > > running the bot.
> >
> > Ok, but why wasn't this spectre-bhb commit asked to be backported to
> > stable in the first place?
> 
> Because it doesn't belong in -stable. Hence the lack of cc:stable or
> fixes: tags.
> 
> > Do older kernels not need these types of
> > fixes?
> >
> 
> This commit was part of a series of six, two of which were bug fixes
> and had fixes: tags. They do not have cc:stable tags because the
> 'fixed' patches had not been backported yet when they were sent out.
> 
> So those are clear candidates for -stable, and as far as I can tell,
> they have already been backported.

Great, thanks for verifying.

> This patch does not fix a bug. It makes the asm code more resilient to
> potential bugs introduced inadvertently by future changes, which will
> be harder to detect now that we have three different versions of the
> exception vector table. (Any given system will only exercise one of
> the three, depending on whether and which Spectre-BHB workaround it
> requires)

Ok, that's good to know, it was not obvious from the changelog text that
this wasn't doing anything but a cleanup.

> I build and boot test my patches carefully, and so I consciously
> decided that the regression risk of backporting this patch outweighs
> the benefits. This is why I did not add a cc:stable or fixes: tag. If
> a tag existed that said 'do not backport this unless explicitly
> requested', I would have added it.
> 
> I would expect anyone that proposes this patch for -stable to be as
> diligent in ensuring that the patch is safe for backporting, which
> includes building the code with older GCC versions that those stable
> kernels still support, and boot testing the result on actual hardware.
> 
> If this is part of the AUTOSEL workflow, then I stand corrected. But
> even then, this does not mean that the patch *belongs* in -stable. As
> you know, I enjoy throwing stable-kernel-rules.rst in your face, and I
> am pretty sure that using a bot to find patches that apply cleanly and
> happen not to cause build breakage is not covered by the criteria
> defined by that document by any stretch of the imagination.
> 
> On top of that, I feel that 'saving' precious stable maintainer's time
> by using a bot to offload this burden to the community uninvited is
> really not ok. We work very hard to keep highly heterogeneous
> architectures such as ARM working across all supported platforms, and
> this is work enough as it is without all the bogus patches that
> AUTOSEL digs up without *any* justification beyond 'hey, it applies!'

If you want to keep arm-core stuff out of the AUTOSEL process, because
you all do a good job of marking stuff already properly, that's fine,
Sasha can easily do that, just let us know.

thanks,

greg k-h

Powered by blists - more mailing lists