[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YxB/ZPFEQG9zS+wa@kroah.com>
Date: Thu, 1 Sep 2022 11:46:12 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Sudip Mukherjee <sudipm.mukherjee@...il.com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
Stable <stable@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Guenter Roeck <linux@...ck-us.net>,
Shuah Khan <shuah@...nel.org>, patches@...nelci.org,
lkft-triage@...ts.linaro.org, Pavel Machek <pavel@...x.de>,
Jonathan Hunter <jonathanh@...dia.com>,
Florian Fainelli <f.fainelli@...il.com>, slade@...dewatkins.com
Subject: Re: [PATCH 5.15 000/136] 5.15.64-rc1 review
On Mon, Aug 29, 2022 at 09:11:28PM +0100, Sudip Mukherjee wrote:
> Hi Greg,
>
> On Mon, Aug 29, 2022 at 12:00 PM Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 5.15.64 release.
> > There are 136 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 Wed, 31 Aug 2022 10:57:37 +0000.
> > Anything received after that time might be too late.
>
> My builds are still running, but just an initial report for gcc-12. (I
> know v5.15.y still does not build completely with gcc-12).
>
> x86_64 and arm64 allmodconfig build fails with gcc-12, with the error:
>
> drivers/acpi/thermal.c: In function 'acpi_thermal_resume':
> drivers/acpi/thermal.c:1101:21: error: the comparison will always
> evaluate as 'true' for the address of 'active' will never be NULL
> [-Werror=address]
> 1101 | if (!(&tz->trips.active[i]))
> | ^
> drivers/acpi/thermal.c:151:36: note: 'active' declared here
> 151 | struct acpi_thermal_active active[ACPI_THERMAL_MAX_ACTIVE];
>
> Will need e5b5d25444e9 ("ACPI: thermal: drop an always true check").
Now applied.
> powerpc allmodconfig fails with gcc-12, the error is:
>
> In function 'memcmp',
> inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:278:9,
> inlined from 'l2cap_global_chan_by_psm' at
> net/bluetooth/l2cap_core.c:2003:15:
> ./include/linux/fortify-string.h:19:33: error: '__builtin_memcmp'
> specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
> 19 | #define __underlying_memcmp __builtin_memcmp
> | ^
> ./include/linux/fortify-string.h:235:16: note: in expansion of macro
> '__underlying_memcmp'
> 235 | return __underlying_memcmp(p, q, size);
> | ^~~~~~~~~~~~~~~~~~~
> In function 'memcmp',
> inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:278:9,
> inlined from 'l2cap_global_chan_by_psm' at
> net/bluetooth/l2cap_core.c:2004:15:
> ./include/linux/fortify-string.h:19:33: error: '__builtin_memcmp'
> specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
> 19 | #define __underlying_memcmp __builtin_memcmp
> | ^
> ./include/linux/fortify-string.h:235:16: note: in expansion of macro
> '__underlying_memcmp'
> 235 | return __underlying_memcmp(p, q, size);
> | ^~~~~~~~~~~~~~~~~~~
>
> Introduced in v5.15.61 due to 2711bedab26c ("Bluetooth: L2CAP: Fix
> l2cap_global_chan_by_psm regression").
> But v5.19.y and mainline does not show the build failure as they also
> have 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only KASAN
> support").
Ick, ok, what to do here? I can't really backport 41b7a347bf14 to 5.15
easily as it's huge and a new feature. Any other ideas?
thanks,
greg k-h
Powered by blists - more mailing lists