Skip to content

Commit e73a7d0

Browse files
mrutland-armnathan-zcgao
authored andcommitted
arm64: stacktrace: Skip reporting LR at exception boundaries
Aishwarya reports that warnings are sometimes seen when running the ftrace kselftests, e.g. | WARNING: CPU: 5 PID: 2066 at arch/arm64/kernel/stacktrace.c:141 arch_stack_walk+0x4a0/0x4c0 | Modules linked in: | CPU: 5 UID: 0 PID: 2066 Comm: ftracetest Not tainted 6.13.0-rc2 #2 | Hardware name: linux,dummy-virt (DT) | pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : arch_stack_walk+0x4a0/0x4c0 | lr : arch_stack_walk+0x248/0x4c0 | sp : ffff800083643d20 | x29: ffff800083643dd0 x28: ffff00007b891400 x27: ffff00007b891928 | x26: 0000000000000001 x25: 00000000000000c0 x24: ffff800082f39d80 | x23: ffff80008003ee8c x22: ffff80008004baa8 x21: ffff8000800533e0 | x20: ffff800083643e10 x19: ffff80008003eec8 x18: 0000000000000000 | x17: 0000000000000000 x16: ffff800083640000 x15: 0000000000000000 | x14: 02a37a802bbb8a92 x13: 00000000000001a9 x12: 0000000000000001 | x11: ffff800082ffad60 x10: ffff800083643d20 x9 : ffff80008003eed0 | x8 : ffff80008004baa8 x7 : ffff800086f2be80 x6 : ffff0000057cf000 | x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff800086f2b690 | x2 : ffff80008004baa8 x1 : ffff80008004baa8 x0 : ffff80008004baa8 | Call trace: | arch_stack_walk+0x4a0/0x4c0 (P) | arch_stack_walk+0x248/0x4c0 (L) | profile_pc+0x44/0x80 | profile_tick+0x50/0x80 (F) | tick_nohz_handler+0xcc/0x160 (F) | __hrtimer_run_queues+0x2ac/0x340 (F) | hrtimer_interrupt+0xf4/0x268 (F) | arch_timer_handler_virt+0x34/0x60 (F) | handle_percpu_devid_irq+0x88/0x220 (F) | generic_handle_domain_irq+0x34/0x60 (F) | gic_handle_irq+0x54/0x140 (F) | call_on_irq_stack+0x24/0x58 (F) | do_interrupt_handler+0x88/0x98 | el1_interrupt+0x34/0x68 (F) | el1h_64_irq_handler+0x18/0x28 | el1h_64_irq+0x6c/0x70 | queued_spin_lock_slowpath+0x78/0x460 (P) The warning in question is: WARN_ON_ONCE(state->common.pc == orig_pc)) ... in kunwind_recover_return_address(), which is triggered when return_to_handler() is encountered in the trace, but ftrace_graph_ret_addr() cannot find a corresponding original return address on the fgraph return stack. This happens because the stacktrace code encounters an exception boundary where the LR was not live at the time of the exception, but the LR happens to contain return_to_handler(); either because the task recently returned there, or due to unfortunate usage of the LR at a scratch register. In such cases attempts to recover the return address via ftrace_graph_ret_addr() may fail, triggering the WARN_ON_ONCE() above and aborting the unwind (hence the stacktrace terminating after reporting the PC at the time of the exception). Handling unreliable LR values in these cases is likely to require some larger rework, so for the moment avoid this problem by restoring the old behaviour of skipping the LR at exception boundaries, which the stacktrace code did prior to commit: c2c6b27 ("arm64: stacktrace: unwind exception boundaries") This commit is effectively a partial revert, keeping the structures and logic to explicitly identify exception boundaries while still skipping reporting of the LR. The logic to explicitly identify exception boundaries is still useful for general robustness and as a building block for future support for RELIABLE_STACKTRACE. Fixes: c2c6b27 ("arm64: stacktrace: unwind exception boundaries") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reported-by: Aishwarya TCV <aishwarya.tcv@arm.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20241211140704.2498712-2-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
1 parent 090a28f commit e73a7d0

File tree

1 file changed

+2
-22
lines changed

1 file changed

+2
-22
lines changed

arch/arm64/kernel/stacktrace.c

Lines changed: 2 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -26,7 +26,6 @@ enum kunwind_source {
2626
KUNWIND_SOURCE_CALLER,
2727
KUNWIND_SOURCE_TASK,
2828
KUNWIND_SOURCE_REGS_PC,
29-
KUNWIND_SOURCE_REGS_LR,
3029
};
3130

3231
union unwind_flags {
@@ -178,23 +177,8 @@ int kunwind_next_regs_pc(struct kunwind_state *state)
178177
state->regs = regs;
179178
state->common.pc = regs->pc;
180179
state->common.fp = regs->regs[29];
181-
state->source = KUNWIND_SOURCE_REGS_PC;
182-
return 0;
183-
}
184-
185-
static __always_inline int
186-
kunwind_next_regs_lr(struct kunwind_state *state)
187-
{
188-
/*
189-
* The stack for the regs was consumed by kunwind_next_regs_pc(), so we
190-
* cannot consume that again here, but we know the regs are safe to
191-
* access.
192-
*/
193-
state->common.pc = state->regs->regs[30];
194-
state->common.fp = state->regs->regs[29];
195180
state->regs = NULL;
196-
state->source = KUNWIND_SOURCE_REGS_LR;
197-
181+
state->source = KUNWIND_SOURCE_REGS_PC;
198182
return 0;
199183
}
200184

@@ -274,11 +258,8 @@ kunwind_next(struct kunwind_state *state)
274258
case KUNWIND_SOURCE_FRAME:
275259
case KUNWIND_SOURCE_CALLER:
276260
case KUNWIND_SOURCE_TASK:
277-
case KUNWIND_SOURCE_REGS_LR:
278-
err = kunwind_next_frame_record(state);
279-
break;
280261
case KUNWIND_SOURCE_REGS_PC:
281-
err = kunwind_next_regs_lr(state);
262+
err = kunwind_next_frame_record(state);
282263
break;
283264
default:
284265
err = -EINVAL;
@@ -436,7 +417,6 @@ static const char *state_source_string(const struct kunwind_state *state)
436417
case KUNWIND_SOURCE_CALLER: return "C";
437418
case KUNWIND_SOURCE_TASK: return "T";
438419
case KUNWIND_SOURCE_REGS_PC: return "P";
439-
case KUNWIND_SOURCE_REGS_LR: return "L";
440420
default: return "U";
441421
}
442422
}

0 commit comments

Comments
 (0)