Commit graph android_kernel_sony_sdm845/arch/arm/kernel/stacktrace.c
Message SHA1
ARM: 8049/1: ftrace/add save_stack_trace_regs() implementation
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>

Lin Yongting   authored and   Russell King   commited 2014-05-30 01:12:32 +01:00
9c98666163
ARM: stacktrace: include exception PC value in stacktrace output
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>

Russell King   commited 2014-05-22 16:33:24 +01:00
07b4034158
ARM: stacktrace: avoid listing stacktrace functions in stacktrace
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>

Russell King   commited 2014-05-22 16:33:19 +01:00
3683f44c42
ARM: 7913/1: fix framepointer check in unwind_frame
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>

Konstantin Khlebnikov   authored and   Russell King   commited 2013-12-09 23:24:33 +00:00
3abb6671a9
arm: convert core files from module.h to export.h
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>

Paul Gortmaker   commited 2011-10-31 19:30:49 -04:00
ecea4ab6d3
ARM: fix /proc/$PID/stack on SMP
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>

Russell King   commited 2011-01-15 09:27:04 +00:00
d5996b2ff0
ARM: 6468/1: backtrace: fix calculation of thread stack base
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>

Will Deacon   authored and   Russell King   commited 2010-11-07 16:12:37 +00:00
d33aadbf8e
[ARM] 5613/1: implement CALLER_ADDRESSx
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>

Uwe Kleine-König   authored and   Russell King   commited 2009-07-21 17:21:28 +01:00
4bf1fa5a34
[ARM] 5382/1: unwind: Reorganise the stacktrace support
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>

Catalin Marinas   authored and   Russell King   commited 2009-02-12 13:21:17 +00:00
2d7c11bfc9
Merge branch 'core/stacktrace' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
* 'core/stacktrace' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  generic-ipi: powerpc/generic-ipi tree build failure
  stacktrace: fix build failure on sparc64
  stacktrace: export save_stack_trace[_tsk]
  stacktrace: fix modular build, export print_stack_trace and save_stack_trace
  backtrace: replace timer with tasklet + completions
  stacktrace: add saved stack traces to backtrace self-test
  stacktrace: print_stack_trace() cleanup
  debugging: make stacktrace independent from DEBUG_KERNEL
  stacktrace: don't crash on invalid stack trace structs

Linus Torvalds   commited 2008-07-15 10:31:35 -07:00
af5329cdf5
stacktrace: export save_stack_trace[_tsk]
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>

Ingo Molnar   commited 2008-07-03 09:17:55 +02:00
7b4c9505f2
[ARM] latencytop support
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>

Nicolas Pitre   authored and   Lennert Buytenhek   commited 2008-06-22 22:44:36 +02:00
f76e915473
[ARM] Fix stacktrace FP range checking
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>

Russell King   commited 2007-05-30 13:15:12 +01:00
5b10c8e436
arm: walk_stacktrace() needs to be exported
oprofile depends on having it

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Al Viro   authored and   Linus Torvalds   commited 2007-05-15 18:56:37 -07:00
7b104bcb8e
[ARM] stacktrace fix
ab1b6f03a1 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>

Andrew Morton   authored and   Russell King   commited 2007-05-11 17:38:50 +01:00
fac0779029
[ARM] Add stacktrace support and make oprofile use it
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>

Russell King   commited 2007-04-28 09:59:37 +01:00
f16fb1ecc5