Re: [PATCH] arch/arm64 : fix error in dump_backtrace

From: Daniel Thompson <daniel.thompson@linaro.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Zhaoyang Huang <huangzhaoyang@gmail.com>,
	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:57:51 +0000	[thread overview]
Message-ID: <20181106085751.hrp7qkp53cftgew6@holly.lan> (raw)
In-Reply-To: <20181106083901.erezwtcomiijvdrk@salmiak>

On Tue, Nov 06, 2018 at 08:39:01AM +0000, Mark Rutland wrote:
> 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.

It's a consequence of having __noreturn isn't it? __noreturn frees the
compiler from the burden of having to produce a valid return stack... so
it doesn't and unwinding becomes hard.

Daniel.

> > [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
> > 