Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAMj1kXEy6n3zZ8Z51kP=tTuOU0xCXLLfC-b6BMpdsjMoM7zGBg@mail.gmail.com>
 <Yh8tWdiWPgZLyQtx@Red> <CAMj1kXGRtdftpoqmd7HBonBBS67jO=YWzoESPAagGfQBZUDQWg@mail.gmail.com>
 <Yh8w7ldudhmbYv4N@Red> <CAMj1kXHri2_tnYhu2gE9xTUOxLY9v1=zODCo1BGfjFTKukiedA@mail.gmail.com>
 <Yh9CbcrfDvN2Z9Y9@Red> <Yh9RI64fThQfnJgS@shell.armlinux.org.uk>
 <CAMj1kXGVwXzAAyDeJqAi+eK1hOB3uShiBb_LORL-_YNvikbsAw@mail.gmail.com>
 <Yh9TdbWwHX/5Bhmt@shell.armlinux.org.uk> <YifuVmkcb1ie7bzk@shell.armlinux.org.uk>
 <Yif+AY3DShT9Z6Q+@shell.armlinux.org.uk>
In-Reply-To: <Yif+AY3DShT9Z6Q+@shell.armlinux.org.uk>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Wed, 9 Mar 2022 08:20:22 +0100
Message-ID: <CAMj1kXFB9sUdxJ8UZQqE6mgSYZH2aB_Y7Ps70C-CS2Pr4U8yOg@mail.gmail.com>
Subject: Re: boot flooded with unwind: Index not found
To:     "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc:     Corentin Labbe <clabbe.montjoie@gmail.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        Arnd Bergmann <arnd@arndb.de>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, 9 Mar 2022 at 02:08, Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> On Wed, Mar 09, 2022 at 12:01:26AM +0000, Russell King (Oracle) wrote:
> > To reinterate what I've just put on IRC - we have not got to the bottom
> > of this problem yet - it still very much exists.
> >
> > There seems to be something of a fundamental issue with the unwinder,
> > it now appears to be going wrong and failing to unwind beyond a
> > couple of functions, and the address it's coming out with appears to
> > be incorrect. I've only just discovered this because I created my very
> > own bug, and yet again, the timing sucks with the proximity of the
> > merge window.
> >
> > I'm getting:
> >
> > [   13.198803] [<c0017728>] (unwind_backtrace) from [<c0012828>] (show_stack+0x10/0x14)
> > [   13.198820] [<c0012828>] (show_stack) from [<c2be78d4>] (0xc2be78d4)
> >
> > for the WARN_ON() stacktrace, and that address that apparently called
> > show_stack() is most definitely rubbish and incorrect. This makes any
> > WARN_ON() condition undebuggable.
> >
> > This is with both 9183/1 and 9184/1 applied on top of pulling your
> > "arm-ftrace-for-rmk" tag and also with just the "arm-vmap-stacks-v6"
> > tag. This seems to point at one of these patches breaking the
> > unwinder:
> >
> > a1c510d0adc6 ARM: implement support for vmap'ed stacks
> > 532319b9c418 ARM: unwind: disregard unwind info before stack frame is set up
>
> The above commit appears to be what's breaking the unwinder. Without
> this I get sane stacktraces. With it, the unwinder spits out stupid
> function addresses.
>

OK, then let's revert that patch. It reduces the likelihood that we
can show a sane stacktrace when the stack overflows, but that is not
the end of the world: the important bit is that it gets caught and
that the offending task is terminated.

We can revisit this in the next cycle.

I do think 9183/1 and 9184/1 should be kept, though. There are
definitely cases such as Corentin's that are different from yours
where we might see spurious warnings otherwise.