Re: [PATCH 5.15 000/117] 5.15.90-rc1 review

From: Ard Biesheuvel
Date: Mon Jan 23 2023 - 02:28:39 EST


On Mon, 23 Jan 2023 at 08:24, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Jan 23, 2023 at 12:39:55PM +0530, Naresh Kamboju wrote:
> > On Sun, 22 Jan 2023 at 20:46, Greg Kroah-Hartman
> > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > This is the start of the stable review cycle for the 5.15.90 release.
> > > There are 117 patches in this series, all will be posted as a response
> > > to this one. If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Tue, 24 Jan 2023 15:02:08 +0000.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.90-rc1.gz
> > > or in the git tree and branch at:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Results from Linaro’s test farm.
> >
> > Reported-by: Linux Kernel Functional Testing <lkft@xxxxxxxxxx>
> >
> > Build regressions found on sh:
> > - build/gcc-8-dreamcast_defconfig
> > - build/gcc-8-microdev_defconfig
> >
> >
> > Build error logs:
> >
> > `.exit.text' referenced in section `__bug_table' of crypto/algboss.o:
> > defined in discarded section `.exit.text' of crypto/algboss.o
> > `.exit.text' referenced in section `__bug_table' of
> > drivers/char/hw_random/core.o: defined in discarded section
> > `.exit.text' of drivers/char/hw_random/core.o
> > make[1]: *** [/builds/linux/Makefile:1218: vmlinux] Error 1
> >
> > Bisection points to this commit,
> > arch: fix broken BuildID for arm64 and riscv
> > commit 99cb0d917ffa1ab628bb67364ca9b162c07699b1 upstream.
> >
> > Ref:
> > upstream discussion thread,
> > https://lore.kernel.org/all/Y7Jal56f6UBh1abE@dev-arch.thelio-3990X/
>
> Argh, what a mess. Ok, let me rip out that commit (and the "fixes up
> that commit") series from the trees and push out a -rc2 in a few hours
> after I wake up. I was worried about that one, and I should have
> trusted my first instinct...
>

The patch in question has

Fixes: 994b7ac1697b ("arm64: remove special treatment for the link
order of head.o")
Fixes: 2348e6bf4421 ("riscv: remove special treatment for the link
order of head.o")

both of which were introduced in the current v6.2 cycle.

Neither of those are marked for stable, are obviously non-stable
material, and were not queued up themselves.

So how did we end up queuing these in the first place?