On Thu, Aug 24, 2023 at 08:08:19AM -0700, Guenter Roeck wrote:
On Thu, Aug 24, 2023 at 03:35:55PM +0200, Greg Kroah-Hartman wrote:
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.
Or maybe just revert all srso patches.
Hah, I wish.
{sigh}
I've notified the patch authors about this, hopefully they can come up with something.
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.
Apparently I am lost in the maze as well. I am quite sure that SRSO only applies to AMD CPUs, and
arch/x86/Kconfig:config CPU_SRSO arch/x86/Kconfig: Enable the SRSO mitigation needed on AMD Zen1-4 machines.
seems to confirm that. What am I missing ? Do you mean the warning that was supposed to be fixed with the objtool patch(es) is only seen on Intel chips ?
Ah, sorry, my confusion (too many different cpu bugs lately)
This might be an issue on AMD chips, but for some reason, in running this kernel on my systems here, I have no boot warnings at all. I blamed it on them being only AMD chips. If that's not the issue then I really have no idea, sorry.
thanks,
greg k-h