[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG48ez0=dtR85yhy07jqvq9YC__3ocT_N_hpJMN4v-FfMs-PsA@mail.gmail.com>
Date: Tue, 25 Mar 2025 03:24:17 +0100
From: Jann Horn <jannh@...gle.com>
To: x86@...nel.org, Andy Lutomirski <luto@...nel.org>, Josh Poimboeuf <jpoimboe@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org,
Dominik Brodowski <linux@...inikbrodowski.net>, Ingo Molnar <mingo@...nel.org>,
Oleg Nesterov <oleg@...hat.com>, Vernon Lovejoy <vlovejoy@...hat.com>
Subject: Re: [PATCH 2/2] x86/dumpstack: Fix broken unwinding from exception stacks
On Tue, Mar 25, 2025 at 3:01 AM Jann Horn <jannh@...gle.com> wrote:
> Originally, get_stack_pointer() used the regs provided by the caller; after
> that commit, get_stack_pointer() instead uses the regs at the top of the
> stack frame the unwinder is looking at. Often, there are no such regs at
> all, and "regs" is NULL, causing get_stack_pointer() to fall back to the
> task's current stack pointer, which is not what we want here, but probably
> happens to mostly work. Other times, the original regs will point to
> another regs frame - in that case, the linear guess unwind logic in
> show_trace_log_lvl() will start unwinding too far up the stack, causing the
> first frame found by the proper unwinder to never be visited, resulting in
> a stack trace consisting purely of guess lines.
I guess the subject line is kind of misleading - maybe "x86/dumpstack:
Fix misplaced assignment in unwinder" would be better?
Powered by blists - more mailing lists