On Mon, 30 May 2022 at 17:25, Greg KH <[email protected]> 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.
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)
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!'
On Mon, May 30, 2022 at 05:56:09PM +0200, Ard Biesheuvel wrote:
> On Mon, 30 May 2022 at 17:25, Greg KH <[email protected]> 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