mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "tip-bot2 for Jann Horn" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: Jann Horn <jannh@google.com>, Ingo Molnar <mingo@kernel.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: [tip: x86/urgent] x86/dumpstack: Fix inaccurate unwinding from exception stacks due to misplaced assignment
Date: Tue, 25 Mar 2025 07:46:15 -0000	[thread overview]
Message-ID: <174288877589.14745.11891370184181289037.tip-bot2@tip-bot2> (raw)
In-Reply-To: <20250325-2025-03-unwind-fixes-v1-2-acd774364768@google.com>

The following commit has been merged into the x86/urgent branch of tip:

Commit-ID:     2c118f50d7fd4d9aefc4533a26f83338b2906b7a
Gitweb:        https://git.kernel.org/tip/2c118f50d7fd4d9aefc4533a26f83338b2906b7a
Author:        Jann Horn <jannh@google.com>
AuthorDate:    Tue, 25 Mar 2025 03:01:23 +01:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Tue, 25 Mar 2025 08:30:43 +01:00

x86/dumpstack: Fix inaccurate unwinding from exception stacks due to misplaced assignment

Commit:

  2e4be0d011f2 ("x86/show_trace_log_lvl: Ensure stack pointer is aligned, again")

was intended to ensure alignment of the stack pointer; but it also moved
the initialization of the "stack" variable down into the loop header.

This was likely intended as a no-op cleanup, since the commit
message does not mention it; however, this caused a behavioral change
because the value of "regs" is different between the two places.

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.

Fix it by moving the "stack = " assignment back where it belongs.

Fixes: 2e4be0d011f2 ("x86/show_trace_log_lvl: Ensure stack pointer is aligned, again")
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20250325-2025-03-unwind-fixes-v1-2-acd774364768@google.com
---
 arch/x86/kernel/dumpstack.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 91639d1..c6fefd4 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -195,6 +195,7 @@ static void show_trace_log_lvl(struct task_struct *task, struct pt_regs *regs,
 	printk("%sCall Trace:\n", log_lvl);
 
 	unwind_start(&state, task, regs, stack);
+	stack = stack ?: get_stack_pointer(task, regs);
 	regs = unwind_get_entry_regs(&state, &partial);
 
 	/*
@@ -213,9 +214,7 @@ static void show_trace_log_lvl(struct task_struct *task, struct pt_regs *regs,
 	 * - hardirq stack
 	 * - entry stack
 	 */
-	for (stack = stack ?: get_stack_pointer(task, regs);
-	     stack;
-	     stack = stack_info.next_sp) {
+	for (; stack; stack = stack_info.next_sp) {
 		const char *stack_name;
 
 		stack = PTR_ALIGN(stack, sizeof(long));

  parent reply	other threads:[~2025-03-25  7:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-25  2:01 [PATCH 0/2] x86 unwind fixes (1 unwinder fix, 1 missing entry ORC annotation) Jann Horn
2025-03-25  2:01 ` [PATCH 1/2] x86/entry: Fix ORC for PUSH_REGS with save_ret=1 Jann Horn
2025-03-25  7:46   ` [tip: x86/urgent] x86/entry: Fix ORC unwinder " tip-bot2 for Jann Horn
2025-03-25  2:01 ` [PATCH 2/2] x86/dumpstack: Fix broken unwinding from exception stacks Jann Horn
2025-03-25  2:24   ` Jann Horn
2025-03-25  7:31     ` Ingo Molnar
2025-03-25  7:46   ` tip-bot2 for Jann Horn [this message]
2025-03-25 13:27   ` Oleg Nesterov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=174288877589.14745.11891370184181289037.tip-bot2@tip-bot2 \
    --to=tip-bot2@linutronix.de \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®