On Mon, May 30, 2022 at 05:56:09PM +0200, Ard Biesheuvel wrote: > On Mon, 30 May 2022 at 17:25, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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
