On Wed, Aug 23, 2023 at 05:50:42PM +0200, Greg Kroah-Hartman wrote:
On Wed, Aug 23, 2023 at 06:30:13AM -0700, Guenter Roeck wrote:
On Wed, Aug 23, 2023 at 01:47:39PM +0530, Naresh Kamboju wrote:
On Wed, 23 Aug 2023 at 12:33, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Tue, Aug 22, 2023 at 05:49:54PM -0700, Guenter Roeck wrote:
On Mon, Aug 21, 2023 at 09:39:39PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.1.47 release. There are 194 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, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.
Build results: total: 157 pass: 156 fail: 1 Failed builds: m68k:sun3_defconfig Qemu test results: total: 521 pass: 519 fail: 2 Failed tests: arm:fuji-bmc:aspeed_g5_defconfig:notests:mem1G:mtd128,0,8,1:net,nic:aspeed-bmc-facebook-fuji:f2fs arm:bletchley-bmc,fmc-model=mt25qu02g,spi-model=mt25qu02g:aspeed_g5_defconfig:notests:mem1G:mtd256:net,nic:aspeed-bmc-facebook-bletchley:f2fs
The m68k build failure is
Inconsistent kallsyms data Try make KALLSYMS_EXTRA_PASS=1 as a workaround
I already have KALLSYMS_EXTRA_PASS=1 enabled, so that doesn't help. Nothing to worry about. The f2fs crashes are still seen. They also happen for other architectures, so it is not just an arm problem. I'll probably just disable all f2fs testing going forward. If so I'll send a note clarifying that the lack of reported test failures doesn't mean that it works.
I'll look into this later this week, next week to resolve the f2fs stuff. I wanted to get to the other known bug fixes first.
For x86 I get the same runtime warning as everyone else.
Yeah, this is troubling...
Is it clang only? I'll dig into this today...
It is seen with gcc-13 and clang-17 with few extra configs. We are not booting defconfig.
The Kconfigs are enabled with KFENCE.
I have KFENCE enabled as well, so it may well be that this triggers the warning. I don't see it in 6.4.y or upstream, though.
Ok, let me rip out all the x86 and objtool patches from this release, get it out the door with the good things in there that everyone else needs, and then we can focus on this mess...
Maybe I'll just backport _all_ objtool changes to sync things up better, last time I tried that it was a maze of twisty passages, all coated in assembly...
I got lost in the maze again today, ick.
Anyway, I give up. I'm just going to push out a -rc1 with just these changes in it today, and if people are upset about the runtime warning, then they can provide a working backport of this objtool patch.
Ideally, the CPU vendor who is causing this mess will do that, as it's their issue we are spending all of this time on, not Linux's issue.
Also, oddly, I can not reproduce this problem here on my hardware at all. Maybe because it's an AMD processor? If so, makes sense, as the SRSO issue is only for Intel chips.
thanks,
greg k-h