Date:   Mon, 23 Jan 2023 08:51:23 +0100
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Ard Biesheuvel <ardb@kernel.org>,
        Tom Saeger <tom.saeger@oracle.com>
Cc:     Naresh Kamboju <naresh.kamboju@linaro.org>, stable@vger.kernel.org,
        patches@lists.linux.dev, linux-kernel@vger.kernel.org,
        torvalds@linux-foundation.org, akpm@linux-foundation.org,
        linux@roeck-us.net, shuah@kernel.org, patches@kernelci.org,
        lkft-triage@lists.linaro.org, pavel@denx.de, jonathanh@nvidia.com,
        f.fainelli@gmail.com, sudipm.mukherjee@gmail.com,
        srw@sladewatkins.net, rwarsow@gmx.de,
        Nathan Chancellor <nathan@kernel.org>,
        Dennis Gilmore <dennis@ausil.us>,
        Palmer Dabbelt <palmer@rivosinc.com>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH 5.15 000/117] 5.15.90-rc1 review
Message-ID: <Y848ey9hzyHf3t8d@kroah.com>
References: <20230122150232.736358800@linuxfoundation.org>
 <CA+G9fYsEvpCj_vSFLxkKA6tzdNOhimqZYF+WCLKYAiNLtrMvsA@mail.gmail.com>
 <Y842R2KIhUL9XMUi@kroah.com>
 <CAMj1kXF02H87N4NsPWCdjdkGz-D_EQVMxbN3=btgzr5F=P0eRQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMj1kXF02H87N4NsPWCdjdkGz-D_EQVMxbN3=btgzr5F=P0eRQ@mail.gmail.com>
Precedence: bulk

On Mon, Jan 23, 2023 at 08:28:18AM +0100, Ard Biesheuvel wrote:
> On Mon, 23 Jan 2023 at 08:24, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> 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@linuxfoundation.org> 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@linaro.org>
> > >
> > > 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?

Because of this long thread:
	https://lore.kernel.org/r/Y842qsBn37yi9OuR@kroah.com
it was requested by Tom to add it (to: him as well.)

I'm dropping the whole series now, and will wait for a working set of
backports to be submitted by Tom before reconsidering them.

thanks,

greg k-h