Re: [PATCH 6.1 000/194] 6.1.47-rc1 review

From: Guenter Roeck
Date: Thu Aug 24 2023 - 11:09:00 EST


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@xxxxxxxxxxxxxxxxxxx> 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.

> 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 ?

Thanks,
Guenter