linux-stable.git/arch/x86/include/asm/stacktrace.h, branch linux-4.8.y

x86: avoid avoid passing around 'thread_info' in stack dumping code

2016-06-23T19:20:01+00:00

None of the code actually wants a thread_info, it all wants a
task_struct, and it's just converting to a thread_info pointer much too
early.

No semantic change.

Signed-off-by: Linus Torvalds

perf: generalize perf_callchain

2016-02-20T05:21:44+00:00

. avoid walking the stack when there is no room left in the buffer
. generalize get_perf_callchain() to be called from bpf helper

Signed-off-by: Alexei Starovoitov 
Signed-off-by: David S. Miller

x86: Remove warning and warning_symbol from struct stacktrace_ops

2011-05-12T13:31:28+00:00

Both warning and warning_symbol are nowhere used.
Let's get rid of them.

Signed-off-by: Richard Weinberger 
Cc: Oleg Nesterov 
Cc: Andrew Morton 
Cc: Huang Ying 
Cc: Soeren Sandmann Pedersen 
Cc: Namhyung Kim 
Cc: x86 
Cc: H. Peter Anvin 
Cc: Thomas Gleixner 
Cc: Robert Richter 
Cc: Paul Mundt 
Link: http://lkml.kernel.org/r/1305205872-10321-2-git-send-email-richard@nod.at
Signed-off-by: Frederic Weisbecker

x86, dumpstack: Correct stack dump info when frame pointer is available

2011-03-18T09:51:42+00:00

Current stack dump code scans entire stack and check each entry
contains a pointer to kernel code. If CONFIG_FRAME_POINTER=y it
could mark whether the pointer is valid or not based on value of
the frame pointer. Invalid entries could be preceded by '?' sign.

However this was not going to happen because scan start point
was always higher than the frame pointer so that they could not
meet.

Commit 9c0729dc8062 ("x86: Eliminate bp argument from the stack
tracing routines") delayed bp acquisition point, so the bp was
read in lower frame, thus all of the entries were marked
invalid.

This patch fixes this by reverting above commit while retaining
stack_frame() helper as suggested by Frederic Weisbecker.

End result looks like below:

before:

 [    3.508329] Call Trace:
 [    3.508551]  [] ? panic+0x91/0x199
 [    3.508662]  [] ? printk+0x68/0x6a
 [    3.508770]  [] ? mount_block_root+0x257/0x26e
 [    3.508876]  [] ? mount_root+0x56/0x5a
 [    3.508975]  [] ? prepare_namespace+0x170/0x1a9
 [    3.509216]  [] ? kernel_init+0x1d2/0x1e2
 [    3.509335]  [] ? kernel_thread_helper+0x4/0x10
 [    3.509442]  [] ? restore_args+0x0/0x30
 [    3.509542]  [] ? kernel_init+0x0/0x1e2
 [    3.509641]  [] ? kernel_thread_helper+0x0/0x10

after:

 [    3.522991] Call Trace:
 [    3.523351]  [] panic+0x91/0x199
 [    3.523468]  [] ? printk+0x68/0x6a
 [    3.523576]  [] mount_block_root+0x257/0x26e
 [    3.523681]  [] mount_root+0x56/0x5a
 [    3.523780]  [] prepare_namespace+0x170/0x1a9
 [    3.523885]  [] kernel_init+0x1d2/0x1e2
 [    3.523987]  [] kernel_thread_helper+0x4/0x10
 [    3.524228]  [] ? restore_args+0x0/0x30
 [    3.524345]  [] ? kernel_init+0x0/0x1e2
 [    3.524445]  [] ? kernel_thread_helper+0x0/0x10

 -v5:
   * fix build breakage with oprofile

 -v4:
   * use 0 instead of regs->bp
   * separate out printk changes

 -v3:
   * apply comment from Frederic
   * add a couple of printk fixes

Signed-off-by: Namhyung Kim 
Acked-by: Peter Zijlstra 
Acked-by: Frederic Weisbecker 
Cc: Soren Sandmann 
Cc: Paul Mackerras 
Cc: Arnaldo Carvalho de Melo 
Cc: Robert Richter 
LKML-Reference: <1300416006-3163-1-git-send-email-namhyung@gmail.com>
Signed-off-by: Ingo Molnar

x86: Eliminate bp argument from the stack tracing routines

2010-11-18T13:37:34+00:00

The various stack tracing routines take a 'bp' argument in which the
caller is supposed to provide the base pointer to use, or 0 if doesn't
have one. Since bp is garbage whenever CONFIG_FRAME_POINTER is not
defined, this means all callers in principle should either always pass
0, or be conditional on CONFIG_FRAME_POINTER.

However, there are only really three use cases for stack tracing:

(a) Trace the current task, including IRQ stack if any
(b) Trace the current task, but skip IRQ stack
(c) Trace some other task

In all cases, if CONFIG_FRAME_POINTER is not defined, bp should just
be 0.  If it _is_ defined, then

- in case (a) bp should be gotten directly from the CPU's register, so
  the caller should pass NULL for regs,

- in case (b) the caller should should pass the IRQ registers to
  dump_trace(),

- in case (c) bp should be gotten from the top of the task's stack, so
  the caller should pass NULL for regs.

Hence, the bp argument is not necessary because the combination of
task and regs is sufficient to determine an appropriate value for bp.

This patch introduces a new inline function stack_frame(task, regs)
that computes the desired bp. This function is then called from the
two versions of dump_stack().

Signed-off-by: Soren Sandmann 
Acked-by: Steven Rostedt 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Peter Zijlstra 
Cc: Arjan van de Ven ,
Cc: Frederic Weisbecker ,
Cc: Arnaldo Carvalho de Melo ,
LKML-Reference: >
Signed-off-by: Frederic Weisbecker

perf: Drop the skip argument from perf_arch_fetch_regs_caller

2010-06-08T21:31:27+00:00

Drop this argument now that we always want to rewind only to the
state of the first caller.
It means frame pointers are not necessary anymore to reliably get
the source of an event. But this also means we need this helper
to be a macro now, as an inline function is not an option since
we need to know when to provide a default implentation.

Signed-off-by: Frederic Weisbecker 
Signed-off-by: Paul Mackerras 
Cc: David Miller 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo

x86: Unify dumpstack.h and stacktrace.h

2010-06-08T21:29:52+00:00

arch/x86/include/asm/stacktrace.h and arch/x86/kernel/dumpstack.h
declare headers of objects that deal with the same topic.
Actually most of the files that include stacktrace.h also include
dumpstack.h

Although dumpstack.h seems more reserved for internals of stack
traces, those are quite often needed to define specialized stack
trace operations. And perf event arch headers are going to need
access to such low level operations anyway. So don't continue to
bother with dumpstack.h as it's not anymore about isolated deep
internals.

v2: fix struct stack_frame definition conflict in sysprof

Signed-off-by: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Thomas Gleixner 
Cc: Soeren Sandmann

perf: Drop useless check for ignored frame

2010-01-13T09:09:08+00:00

The check that ignores the debug and nmi stack frames is useless
now that we have a frame pointer that makes us start at the
right place. We don't anymore have to deal with these.

Signed-off-by: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo 
Cc: Paul Mackerras 
LKML-Reference: <1262235183-5320-2-git-send-regression-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar

perf events, x86/stacktrace: Fix performance/softlockup by providing a special frame pointer-only stack walker

2009-12-17T09:42:52+00:00

It's just wasteful for stacktrace users like perf to walk
through every entries on the stack whereas these only accept
reliable ones, ie: that the frame pointer validates.

Since perf requires pure reliable stacktraces, it needs a stack
walker based on frame pointers-only to optimize the stacktrace
processing.

This might solve some near-lockup scenarios that can be triggered
by call-graph tracing timer events.

Signed-off-by: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo 
Cc: Paul Mackerras 
LKML-Reference: <1261024834-5336-2-git-send-regression-fweisbec@gmail.com>
[ v2: fix for modular builds and small detail tidyup ]
Signed-off-by: Ingo Molnar

perf events, x86/stacktrace: Make stack walking optional

2009-12-17T08:56:19+00:00

The current print_context_stack helper that does the stack
walking job is good for usual stacktraces as it walks through
all the stack and reports even addresses that look unreliable,
which is nice when we don't have frame pointers for example.

But we have users like perf that only require reliable
stacktraces, and those may want a more adapted stack walker, so
lets make this function a callback in stacktrace_ops that users
can tune for their needs.

Signed-off-by: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo 
Cc: Paul Mackerras 
LKML-Reference: <1261024834-5336-1-git-send-regression-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar