From: Mark Rutland <mark.rutland@arm.com>
To: Zhaoyang Huang <huangzhaoyang@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Dave Martin <dave.martin@arm.com>,
Michael Weiser <michael.weiser@gmx.de>,
James Morse <james.morse@arm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arch/arm64 : fix error in dump_backtrace
Date: Tue, 6 Nov 2018 08:39:01 +0000 [thread overview]
Message-ID: <20181106083901.erezwtcomiijvdrk@salmiak> (raw)
In-Reply-To: <1541488775-29610-1-git-send-email-huangzhaoyang@gmail.com>
On Tue, Nov 06, 2018 at 03:19:35PM +0800, Zhaoyang Huang wrote:
> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>
> In some cases, the instruction of "bl foo1" will be the last one of the
> foo2[1], which will cause the lr be the first instruction of the adjacent
> foo3[2]. Hence, the backtrace will show the weird result as bellow[3].
> The patch will fix it by miner 4 of the lr when dump_backtrace
This has come up in the past (and a similar patch has been applied, then
reverted).
In general, we don't know that a function call was made via BL, and therefore
cannot know that LR - 4 is the address of the caller. The caller could set up
the LR as it likes, then B or BR to the callee, and depending on how the basic
blocks get laid out in memory, LR - 4 might point at something completely
different.
More ideally, the compiler wouldn't end a function with a BL. When does that
happen, and is there some way we could arrange for that to not happen? e.g.
somehow pad a NOP after the BL.
Thanks,
Mark.
>
> [1]
> 0xffffff80081e6b04 <handle_mm_fault+3996>: adrp x0, 0xffffff8008ca8000
> 0xffffff80081e6b08 <handle_mm_fault+4000>: add x0, x0, #0x5a8
> 0xffffff80081e6b0c <handle_mm_fault+4004>: bl 0xffffff80081b0ca0 <panic>
> 0xffffff80081e6b10 <access_remote_vm>: stp x29, x30, [sp,#-64]!
> 0xffffff80081e6b14 <access_remote_vm+4>: mov x29, sp
>
> [2]
> crash_arm64> rd ffffffc02eec3bd0 2
> ffffffc02eec3bd0: ffffffc02eec3cb0 ffffff80081e6b10
>
> [3]
> wrong:
> [<ffffff80081b0d90>] panic+0xf0/0x24c
> [<ffffff80081e6b10>] access_remote_vm+0x0/0x5c
> [<ffffff800809d7b0>] do_page_fault+0x290/0x3b8
> [<ffffff8008081570>] do_mem_abort+0x64/0xdc
>
> correct:
> [ffffffc02eec3bd0] panic at ffffff80081b0da4
> [ffffffc02eec3cb0] handle_mm_fault at ffffff80081e6b0c
> [ffffffc02eec3d80] do_page_fault at ffffff800809d7ac
> [ffffffc02eec3df0] do_mem_abort at ffffff800808156c
>
> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> ---
> arch/arm64/kernel/traps.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index d399d45..7a097cc 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -113,7 +113,7 @@ void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
>
> if (tsk == current) {
> frame.fp = (unsigned long)__builtin_frame_address(0);
> - frame.pc = (unsigned long)dump_backtrace;
> + frame.pc = (unsigned long)dump_backtrace + 4;
> } else {
> /*
> * task blocked in __switch_to
> @@ -130,7 +130,7 @@ void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
> do {
> /* skip until specified stack frame */
> if (!skip) {
> - dump_backtrace_entry(frame.pc);
> + dump_backtrace_entry(frame.pc - 4);
> } else if (frame.fp == regs->regs[29]) {
> skip = 0;
> /*
> --
> 1.9.1
>
next prev parent reply other threads:[~2018-11-06 8:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-06 7:19 [PATCH] arch/arm64 : fix error in dump_backtrace Zhaoyang Huang
2018-11-06 8:39 ` Mark Rutland [this message]
2018-11-06 8:57 ` Daniel Thompson
2018-11-06 11:00 ` Mark Rutland
2018-11-06 11:32 ` Dave P Martin
2018-11-06 12:29 ` Mark Rutland
2018-11-06 14:24 ` Dave Martin
2018-11-06 12:05 ` Daniel Thompson
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=20181106083901.erezwtcomiijvdrk@salmiak \
--to=mark.rutland@arm.com \
--cc=catalin.marinas@arm.com \
--cc=dave.martin@arm.com \
--cc=huangzhaoyang@gmail.com \
--cc=james.morse@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.weiser@gmx.de \
--cc=will.deacon@arm.com \
/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