From: Mark Rutland <mark.rutland@arm.com>
To: linux-arm-kernel@lists.infradead.org
Cc: aou@eecs.berkeley.edu, borntraeger@de.ibm.com, bp@alien8.de,
broonie@kernel.org, catalin.marinas@arm.com,
dave.hansen@linux.intel.com, gor@linux.ibm.com,
hca@linux.ibm.com, linux-kernel@vger.kernel.org,
madvenka@linux.microsoft.com, mark.rutland@arm.com,
mhiramat@kernel.org, mingo@redhat.com, mpe@ellerman.id.au,
palmer@dabbelt.com, paul.walmsley@sifive.com,
peterz@infradead.org, rostedt@goodmis.org, tglx@linutronix.de,
will@kernel.org
Subject: [PATCH 8/9] arm64: Make dump_backtrace() use arch_stack_walk()
Date: Wed, 17 Nov 2021 14:07:36 +0000 [thread overview]
Message-ID: <20211117140737.44420-9-mark.rutland@arm.com> (raw)
In-Reply-To: <20211117140737.44420-1-mark.rutland@arm.com>
From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
To enable RELIABLE_STACKTRACE and LIVEPATCH on arm64, we need to
substantially rework arm64's unwinding code. As part of this, we want to
minimize the set of unwind interfaces we expose, and avoid open-coding
of unwind logic.
Currently, dump_backtrace() walks the stack of the current task or a
blocked task by calling stact_backtrace() and iterating unwind steps
using unwind_frame(). This can be written more simply in terms of
arch_stack_walk(), considering three distinct cases:
1) When unwinding a blocked task, start_backtrace() is called with the
blocked task's saved PC and FP, and the unwind proceeds immediately
from this point without skipping any entries. This is functionally
equivalent to calling arch_stack_walk() with the blocked task, which
will start with the task's saved PC and FP.
There is no functional change to this case.
2) When unwinding the current task without regs, start_backtrace() is
called with dump_backtrace() as the PC and __builtin_frame_address(0)
as the next frame, and the unwind proceeds immediately without
skipping. This is *almost* functionally equivalent to calling
arch_stack_walk() for the current task, which will start with its
caller (i.e. an offset into dump_backtrace()) as the PC, and the
callers frame record as the next frame.
The only difference being that dump_backtrace() will be reported with
an offset (which is strictly more correct than currently). Otherwise
there is no functional cahnge to this case.
3) When unwinding the current task with regs, start_backtrace() is
called with dump_backtrace() as the PC and __builtin_frame_address(0)
as the next frame, and the unwind is performed silently until the
next frame is the frame pointed to by regs->fp. Reporting starts
from regs->pc and continues from the frame in regs->fp.
Historically, this pre-unwind was necessary to correctly record
return addresses rewritten by the ftrace graph calller, but this is
no longer necessary as these are now recovered using the FP since
commit:
c6d3cd32fd0064af ("arm64: ftrace: use HAVE_FUNCTION_GRAPH_RET_ADDR_PTR")
This pre-unwind is not necessary to recover return addresses
rewritten by kretprobes, which historically were not recovered, and
are now recovered using the FP since commit:
cd9bc2c9258816dc ("arm64: Recover kretprobe modified return address in stacktrace")
Thus, this is functionally equivalent to calling arch_stack_walk()
with the current task and regs, which will start with regs->pc as the
PC and regs->fp as the next frame, without a pre-unwind.
This patch makes dump_backtrace() use arch_stack_walk(). This simplifies
dump_backtrace() and will permit subsequent changes to the unwind code.
Aside from the improved reporting when unwinding current without regs,
there should be no functional change as a result of this patch.
Signed-off-by: Madhavan T. Venkataraman <madvenka@linux.microsoft.com>
[Mark: elaborate commit message]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
---
arch/arm64/kernel/stacktrace.c | 44 ++++++------------------------------------
1 file changed, 6 insertions(+), 38 deletions(-)
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index e6ba6b000564..9fc771a05306 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -156,24 +156,20 @@ void notrace walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
}
NOKPROBE_SYMBOL(walk_stackframe);
-static void dump_backtrace_entry(unsigned long where, const char *loglvl)
+static bool dump_backtrace_entry(void *arg, unsigned long where)
{
+ char *loglvl = arg;
printk("%s %pSb\n", loglvl, (void *)where);
+ return true;
}
void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
const char *loglvl)
{
- struct stackframe frame;
- int skip = 0;
-
pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
- if (regs) {
- if (user_mode(regs))
- return;
- skip = 1;
- }
+ if (regs && user_mode(regs))
+ return;
if (!tsk)
tsk = current;
@@ -181,36 +177,8 @@ void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
if (!try_get_task_stack(tsk))
return;
- if (tsk == current) {
- start_backtrace(&frame,
- (unsigned long)__builtin_frame_address(0),
- (unsigned long)dump_backtrace);
- } else {
- /*
- * task blocked in __switch_to
- */
- start_backtrace(&frame,
- thread_saved_fp(tsk),
- thread_saved_pc(tsk));
- }
-
printk("%sCall trace:\n", loglvl);
- do {
- /* skip until specified stack frame */
- if (!skip) {
- dump_backtrace_entry(frame.pc, loglvl);
- } else if (frame.fp == regs->regs[29]) {
- skip = 0;
- /*
- * Mostly, this is the case where this function is
- * called in panic/abort. As exception handler's
- * stack frame does not contain the corresponding pc
- * at which an exception has taken place, use regs->pc
- * instead.
- */
- dump_backtrace_entry(regs->pc, loglvl);
- }
- } while (!unwind_frame(tsk, &frame));
+ arch_stack_walk(dump_backtrace_entry, (void *)loglvl, tsk, regs);
put_task_stack(tsk);
}
--
2.11.0
next prev parent reply other threads:[~2021-11-17 14:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-17 14:07 [PATCH 0/9] arm64: stacktrace: unify unwind code Mark Rutland
2021-11-17 14:07 ` [PATCH 1/9] arch: Make ARCH_STACKWALK independent of STACKTRACE Mark Rutland
2021-11-17 14:07 ` [PATCH 2/9] arm64: Add comment for stack_info::kr_cur Mark Rutland
2021-11-17 15:23 ` Mark Brown
2021-11-18 22:25 ` Masami Hiramatsu
2021-11-23 11:47 ` Mark Rutland
2021-11-17 14:07 ` [PATCH 3/9] arm64: Mark __switch_to() as __sched Mark Rutland
2021-11-17 15:42 ` Mark Brown
2021-11-17 14:07 ` [PATCH 4/9] arm64: Make perf_callchain_kernel() use arch_stack_walk() Mark Rutland
2021-11-17 14:07 ` [PATCH 5/9] arm64: Make __get_wchan() " Mark Rutland
2021-11-17 15:50 ` Mark Brown
2021-11-17 14:07 ` [PATCH 6/9] arm64: Make return_address() " Mark Rutland
2021-11-17 14:07 ` [PATCH 7/9] arm64: Make profile_pc() " Mark Rutland
2021-11-17 15:31 ` Mark Brown
2021-11-17 14:07 ` Mark Rutland [this message]
2021-11-17 15:36 ` [PATCH 8/9] arm64: Make dump_backtrace() " Mark Brown
2021-11-17 14:07 ` [PATCH 9/9] arm64: Make some stacktrace functions private Mark Rutland
2021-11-17 15:39 ` Mark Brown
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=20211117140737.44420-9-mark.rutland@arm.com \
--to=mark.rutland@arm.com \
--cc=aou@eecs.berkeley.edu \
--cc=borntraeger@de.ibm.com \
--cc=bp@alien8.de \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=madvenka@linux.microsoft.com \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=will@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®