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: <20221209112500.GA3116@willie-the-truck>
In-Reply-To: <20221209112500.GA3116@willie-the-truck>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon, 12 Dec 2022 10:05:07 -0800
Message-ID: <CAHk-=wj-8gKB5SG0w_M2fK0KYyhZbNzDZ1W9H5pmisWzJ0XJEw@mail.gmail.com>
Subject: Re: [GIT PULL] arm64 updates for 6.2
To:     Will Deacon <will@kernel.org>
Cc:     catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, kernel-team@android.com,
        maz@kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Dec 9, 2022 at 3:25 AM Will Deacon <will@kernel.org> wrote:
>
> Dynamic SCS:
>         * Support for dynamic shadow call stacks to allow switching at
>           runtime between Clang's SCS implementation and the CPU's
>           pointer authentication feature when it is supported (complete
>           with scary DWARF parser!)

I've pulled this thing, but this part makes me nervous. There's some
bad history with debug information not being 100% reliable probably
simply because it gets very little correctness testing.

It might be worth thinking about at least verifying the information
using something like objtool, so that you at least catch problem cases
at *build* time rather than runtime.

For example, that whole

    default:
        pr_err("unhandled opcode: %02x in FDE frame %lx\n",
opcode[-1], (uintptr_t)frame);
        return -ENOEXEC;

really makes me go "this should have been verified at build time, it's
much too late to notice now that you don't understand the dwarf data".

Hmm?

                    Linus