summaryrefslogtreecommitdiff
path: root/arch/arm/kernel/stacktrace.c (unfollow)
Commit message (Collapse)Author
2021-11-26ARM: clang: Do not rely on lr register for stacktraceMasami Hiramatsu
[ Upstream commit b3ea5d56f212ad81328c82454829a736197ebccc ] Currently the stacktrace on clang compiled arm kernel uses the 'lr' register to find the first frame address from pt_regs. However, that is wrong after calling another function, because the 'lr' register is used by 'bl' instruction and never be recovered. As same as gcc arm kernel, directly use the frame pointer (r11) of the pt_regs to find the first frame address. Note that this fixes kretprobe stacktrace issue only with CONFIG_UNWINDER_FRAME_POINTER=y. For the CONFIG_UNWINDER_ARM, we need another fix. Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-08-21ARM: 8992/1: Fix unwind_frame for clang-built kernelsNathan Huckleberry
commit b4d5ec9b39f8b31d98f65bc5577b5d15d93795d7 upstream. Since clang does not push pc and sp in function prologues, the current implementation of unwind_frame does not work. By using the previous frame's lr/fp instead of saved pc/sp we get valid unwinds on clang-built kernels. The bounds check on next frame pointer must be changed as well since there are 8 less bytes between frames. This fixes /proc/<pid>/stack. Link: https://github.com/ClangBuiltLinux/linux/issues/912 Reported-by: Miles Chen <miles.chen@mediatek.com> Tested-by: Miles Chen <miles.chen@mediatek.com> Cc: stable@vger.kernel.org Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Huckleberry <nhuck@google.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-22arm/arm64: Export save_stack_trace_tsk()Dustin Brown
The kernel watchdog is a great debugging tool for finding tasks that consume a disproportionate amount of CPU time in contiguous chunks. One can imagine building a similar watchdog for arbitrary driver threads using save_stack_trace_tsk() and print_stack_trace(). However, this is not viable for dynamically loaded driver modules on ARM platforms because save_stack_trace_tsk() is not exported for those architectures. Export save_stack_trace_tsk() for the ARM64 architecture to align with x86 and support various debugging use cases such as arbitrary driver thread watchdog timers. Change-Id: I61e9d2afc4703a786fa6dcaf82fe46c0ed250045 CRs-Fixed: 2061326 Signed-off-by: Dustin Brown <dustinb@codeaurora.org>
2016-03-01arm: kernel: Ignore KASan errors from unwind_frameSe Wang (Patrick) Oh
When a process A unwind the stack frame of process B, the stack of B can be modified and updated in other CPU concurrently. So KASan could examine stack address with out of date shadow mask value. To avoid this incorrect KASan report, disable KASan during unwinding a frame of a different task. Following is the Kasan error log for the reference. ================================================================== BUG: KASan: out of bounds access in unwind_frame+0x9c/0xf8 at addr ffffffc0462b76f0 Read of size 8 by task Signal Catcher/1282 page:ffffffbac7bdb260 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x0() page dumped because: kasan: bad access detected Call trace: [<ffffffc00008c010>] dump_backtrace+0x0/0x250 [<ffffffc00008c270>] show_stack+0x10/0x1c [<ffffffc001b6e628>] dump_stack+0x74/0xfc [<ffffffc0002dd7c4>] kasan_report_error+0x2b0/0x408 [<ffffffc0002dd9f8>] kasan_report+0x34/0x40 [<ffffffc0002dda78>] __asan_report_load8_noabort+0x14/0x20 [<ffffffc00008b984>] unwind_frame+0x98/0xf8 [<ffffffc00008ba14>] walk_stackframe+0x30/0x48 [<ffffffc00008bba4>] save_stack_trace_tsk+0x178/0x254 [<ffffffc0003a5bc4>] proc_pid_stack+0xf0/0x198 [<ffffffc0003a11b0>] proc_single_show+0xe8/0x130 [<ffffffc000330e0c>] seq_read+0x524/0xaf0 [<ffffffc0002e9c74>] vfs_read+0x120/0x270 [<ffffffc0002eb208>] SyS_read+0xec/0x198 Memory state around the buggy address: ffffffc0462b7580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0462b7600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffc0462b7680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ffffffc0462b7700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0462b7780: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 ================================================================== Change-Id: I0e35e6721417fa7a5bffb41be67443cd906e256a Signed-off-by: Se Wang (Patrick) Oh <sewango@codeaurora.org>
2014-11-13ARM: 8172/1: Use current_stack_pointer in save_stack_trace_tskBehan Webster
Use the global current_stack_pointer to get the value of the stack pointer. This change supports being able to compile the kernel with both gcc and clang. Signed-off-by: Behan Webster <behanw@converseincode.com> Reviewed-by: Mark Charlebois <charlebm@gmail.com> Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2014-05-30ARM: 8049/1: ftrace/add save_stack_trace_regs() implementationLin Yongting
When configure kprobe events of ftrace with "stacktrace" option enabled in arm, there is no stacktrace was recorded after the kprobe event was triggered. The root cause is no save_stack_trace_regs() function implemented. Implement the save_stack_trace_regs() function in arm, then ftrace will call this architecture-related function to record the stacktrace into ring buffer. After this fix, stacktrace can be recorded, for example: # mount -t debugfs nodev /sys/kernel/debug # echo "p:netrx net_rx_action" >> /sys/kernel/debug/tracing/kprobe_events # echo 1 > /sys/kernel/debug/tracing/events/kprobes/netrx/enable # echo 1 > /sys/kernel/debug/tracing/options/stacktrace # echo 1 > /sys/kernel/debug/tracing/tracing_on # ping 127.0.0.1 -c 1 # echo 0 > /sys/kernel/debug/tracing/tracing_on # cat /sys/kernel/debug/tracing/trace # tracer: nop # # entries-in-buffer/entries-written: 12/12 #P:1 # # _-----=> irqs-off # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / delay # TASK-PID CPU# |||| TIMESTAMP FUNCTION # | | | |||| | | <------ missing some entries ----------------> ping-1200 [000] dNs1 667.603250: netrx: (net_rx_action+0x0/0x1f8) ping-1200 [000] dNs1 667.604738: <stack trace> => net_rx_action => do_softirq => local_bh_enable => ip_finish_output => ip_output => ip_local_out => ip_send_skb => ip_push_pending_frames => raw_sendmsg => inet_sendmsg => sock_sendmsg => SyS_sendto => ret_fast_syscall Signed-off-by: Lin Yongting <linyongting@gmail.com> Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2014-05-22ARM: stacktrace: include exception PC value in stacktrace outputRussell King
When we unwind through an exception stack, include the saved PC value into the stack trace: this fills in an otherwise missed functions from the trace (as indicated below): [<c03f4424>] fec_enet_interrupt+0xa0/0xe8 [<c0066c0c>] handle_irq_event_percpu+0x68/0x228 [<c0066e18>] handle_irq_event+0x4c/0x6c [<c006a024>] handle_fasteoi_irq+0xac/0x198 [<c00664b0>] generic_handle_irq+0x4c/0x60 [<c000f014>] handle_IRQ+0x40/0x98 [<c0008554>] gic_handle_irq+0x30/0x64 [<c0012900>] __irq_svc+0x40/0x50 [<c0029030>] __do_softirq+0xe0/0x2fc <==== [<c0029500>] irq_exit+0xb0/0x100 [<c000f018>] handle_IRQ+0x44/0x98 [<c0008554>] gic_handle_irq+0x30/0x64 [<c0012900>] __irq_svc+0x40/0x50 [<c000f34c>] arch_cpu_idle+0x30/0x38 <==== [<c005e1e4>] cpu_startup_entry+0xac/0x214 [<c066297c>] rest_init+0x68/0x80 [<c08ccb10>] start_kernel+0x2fc/0x358 Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2014-05-22ARM: stacktrace: avoid listing stacktrace functions in stacktraceRussell King
While debugging the FEC ethernet driver using stacktrace, it was noticed that the stacktraces always begin as follows: [<c00117b4>] save_stack_trace_tsk+0x0/0x98 [<c0011870>] save_stack_trace+0x24/0x28 ... This is because the stack trace code includes the stack frames for itself. This is incorrect behaviour, and also leads to "skip" doing the wrong thing (which is the number of stack frames to avoid recording.) Perversely, it does the right thing when passed a non-current thread. Fix this by ensuring that we have a known constant number of frames above the main stack trace function, and always skip these. Cc: <stable@vger.kernel.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-12-09ARM: 7913/1: fix framepointer check in unwind_frameKonstantin Khlebnikov
This patch fixes corner case when (fp + 4) overflows unsigned long, for example: fp = 0xFFFFFFFF -> fp + 4 == 3. Cc: <stable@vger.kernel.org> Signed-off-by: Konstantin Khlebnikov <k.khlebnikov@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-10-31arm: convert core files from module.h to export.hPaul Gortmaker
Many of the core ARM kernel files are not modules, but just including module.h for exporting symbols. Now these files can use the lighter footprint export.h for this role. There are probably lots more, but ARM files of mach-* and plat-* don't get coverage via a simple yesconfig build. They will have to be cleaned up and tested via using their respective configs. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-01-15ARM: fix /proc/$PID/stack on SMPRussell King
Rabin Vincent reports: | On SMP, this BUG() in save_stack_trace_tsk() can be easily triggered | from user space by reading /proc/$PID/stack, where $PID is any pid but | the current process: | | if (tsk != current) { | #ifdef CONFIG_SMP | /* | * What guarantees do we have here that 'tsk' | * is not running on another CPU? | */ | BUG(); | #else Fix this by replacing the BUG() with an entry to terminate the stack trace, returning an empty trace - I'd rather not expose the dwarf unwinder to a volatile stack of a running thread. Reported-by: Rabin Vincent <rabin@rab.in> Tested-by: Rabin Vincent <rabin@rab.in> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-11-07ARM: 6468/1: backtrace: fix calculation of thread stack baseWill Deacon
When unwinding stack frames we must take care not to unwind areas of memory that lie outside of the known extent of the stack. This patch fixes an incorrect calculation of the stack base where THREAD_SIZE is added to the stack pointer after it has already been aligned to this value. Since the ALIGN macro performs this addition internally, we end up overshooting the base by 8k. Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-07-21[ARM] 5613/1: implement CALLER_ADDRESSxUwe Kleine-König
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> As __builtin_return_address(n) doesn't work for ARM with n > 0, the kernel needs its own implementation. This fixes many warnings saying: warning: unsupported argument to '__builtin_return_address' The new methods and walk_stackframe must not be instrumented because CALLER_ADDRESSx is used in the various tracers and tracing the tracer is a bad idea. What's currently missing is an implementation using unwind tables. This is not fatal though, it's just that the tracers don't get enough information to be really useful. Note that if both ARM_UNWIND and FRAME_POINTER are enabled, walk_stackframe uses unwind information. So in this case the same implementation is used as when FRAME_POINTER is disabled. Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-02-12[ARM] 5382/1: unwind: Reorganise the stacktrace supportCatalin Marinas
This patch changes the walk_stacktrace and its callers for easier integration of stack unwinding. The arch/arm/kernel/stacktrace.h file is also moved to arch/arm/include/asm/stacktrace.h. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-07-03stacktrace: export save_stack_trace[_tsk]Ingo Molnar
Andrew Morton reported this against linux-next: ERROR: ".save_stack_trace" [tests/backtracetest.ko] undefined! Reported-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-06-22[ARM] latencytop supportNicolas Pitre
Available for !SMP only at the moment. From Russell: |Basically, if a thread is running on a CPU, thread_saved_fp() is invalid. |So, the question is: what guarantees do we have here that 'tsk' is not |running on another CPU? Signed-off-by: Nicolas Pitre <nico@marvell.com> Tested-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
2007-05-30[ARM] Fix stacktrace FP range checkingRussell King
Fix an oops in the stacktrace code, caused by improper range checking. We subtract 12 off 'fp' before testing to see if it's below the low bound. However, if 'fp' were zero before, it becomes a very large positive number, causing this test to succeed where it should fail. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-05-15arm: walk_stacktrace() needs to be exportedAl Viro
oprofile depends on having it Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-11[ARM] stacktrace fixAndrew Morton
ab1b6f03a10ba1f5638188ab06bf46e33ac3a160 said - remove the unused task argument to save_stack_trace, it's always current then broke arm: arch/arm/kernel/stacktrace.c:56: error: conflicting types for 'save_stack_trace' include/linux/stacktrace.h:11: error: previous declaration of 'save_stack_trace' was here arch/arm/kernel/stacktrace.c:56: error: conflicting types for 'save_stack_trace' include/linux/stacktrace.h:11: error: previous declaration of 'save_stack_trace' was here Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-04-28[ARM] Add stacktrace support and make oprofile use itRussell King
Add support for stacktrace. Use the new stacktrace code with oprofile instead of it's version; there's no point having multiple versions of stacktracing in the kernel. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>