Re: [PATCH 5.15 000/145] 5.15.103-rc1 review

From: Greg Kroah-Hartman
Date: Thu Mar 16 2023 - 04:00:11 EST


On Wed, Mar 15, 2023 at 08:29:45AM -0600, Daniel Díaz wrote:
> Hello!
>
> On 15/03/23 06:11, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.15.103 release.
> > There are 145 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 Fri, 17 Mar 2023 11:57:10 +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.103-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
>
> We're seeing PowerPC build failures like the following (GCC-8, GCC-12, Clang-16):
>
> -----8<-----
> In file included from /builds/linux/drivers/usb/host/ehci-hcd.c:1298:
> /builds/linux/drivers/usb/host/ehci-ppc-of.c:122:13: error: use of undeclared identifier 'NO_IRQ'
> if (irq == NO_IRQ) {
> ^
> 1 error generated.
> ----->8-----

Will be fixed in -rc2

>
> Then, Perf fails on Arm and i386 with GCC-12:
>
> -----8<-----
> In function 'parse_events_term__num',
> inlined from 'parse_events_multi_pmu_add' at util/parse-events.c:1687:9:
> util/parse-events.c:3100:64: error: array subscript 'YYLTYPE[0]' is partly outside array bounds of 'char[4]' [-Werror=array-bounds]
> 3100 | .err_term = loc_term ? loc_term->first_column : 0,
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
> util/parse-events.c: In function 'parse_events_multi_pmu_add':
> util/parse-events.c:1678:39: note: object 'config' of size 4
> 1678 | char *config;
> | ^~~~~~
> cc1: all warnings being treated as errors
> ----->8-----

This is odd as this file isn't modified, but other build fixes for perf
for 5.15 were made. Let's see if this still happens in -rc2 and if so,
if you could bisect to track down the offending commit that would be
great.

thanks,

greg k-h