15 Jun, 2011

1 commit

  • Swap the 1st and 2nd parameters of save_stack_trace_regs()
    as same as the parameters of save_stack_trace_tsk().

    Signed-off-by: Masami Hiramatsu
    Cc: yrl.pp-manager.tt@hitachi.com
    Cc: Frederic Weisbecker
    Cc: Peter Zijlstra
    Cc: Namhyung Kim
    Link: http://lkml.kernel.org/r/20110608070921.17777.31103.stgit@fedora15
    Signed-off-by: Steven Rostedt

    Masami Hiramatsu
     

12 May, 2011

1 commit

  • 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

    Richard Weinberger
     

18 Mar, 2011

1 commit

  • 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:
    Signed-off-by: Ingo Molnar

    Namhyung Kim
     

18 Nov, 2010

1 commit

  • 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

    Soeren Sandmann Pedersen
     

09 Jun, 2010

3 commits

  • Cleanup. Factor the common code in save_stack_address() and
    save_stack_address_nosched().

    Signed-off-by: Oleg Nesterov
    Cc: Roland McGrath
    Cc: Arjan van de Ven
    Cc: Vegard Nossum
    Cc: Ingo Molnar
    LKML-Reference:
    Signed-off-by: Frederic Weisbecker

    Oleg Nesterov
     
  • If CONFIG_FRAME_POINTER=n, print_context_stack() shouldn't neglect the
    non-reliable addresses on stack, this is all we have if dump_trace(bp)
    is called with the wrong or zero bp.

    For example, /proc/pid/stack doesn't work if CONFIG_FRAME_POINTER=n.

    This patch obviously has no effect if CONFIG_FRAME_POINTER=y, otherwise
    it reverts 1650743c "x86: don't save unreliable stack trace entries".

    Also, remove the unnecessary type-cast.

    Signed-off-by: Oleg Nesterov
    Cc: Roland McGrath
    Cc: Arjan van de Ven
    Cc: Vegard Nossum
    Cc: Ingo Molnar
    Cc: Andrew Morton
    LKML-Reference:
    Signed-off-by: Frederic Weisbecker

    Oleg Nesterov
     
  • 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

    Frederic Weisbecker
     

17 Dec, 2009

1 commit

  • 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:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

13 Jun, 2009

1 commit

  • This will help kmemcheck (and possibly other debugging tools) since we
    can now simply pass regs->bp to the stack tracer instead of specifying
    the number of stack frames to skip, which is unreliable if gcc decides
    to inline functions, etc.

    Note that this makes the API incomplete for other architectures, but I
    expect that those can be updated lazily, e.g. when they need it.

    Cc: Arjan van de Ven
    Signed-off-by: Vegard Nossum

    Vegard Nossum
     

15 May, 2009

1 commit

  • If we return -1 in the ops->stack for the stacktrace saving, we end up
    breaking out of the loop if the stack we are tracing is in the exception
    stack. This causes traces like:

    -0 [002] 34263.745825: raise_softirq_irqoff -0 [002] 34263.745826:
    -0 [003] 883.280992: raise_softirq_irqoff -0 [003] 883.280992:

    Steven Rostedt
     

31 Jan, 2009

1 commit


23 Nov, 2008

2 commits


30 Jun, 2008

1 commit


26 Feb, 2008

1 commit

  • Currently, there is no way for print_stack_trace() to determine whether
    a given stack trace entry was deemed reliable or not, simply because
    save_stack_trace() does not record this information. (Perhaps needless
    to say, this makes the saved stack traces A LOT harder to read, and
    probably with no other benefits, since debugging features that use
    save_stack_trace() most likely also require frame pointers, etc.)

    This patch reverts to the old behaviour of only recording the reliable trace
    entries for saved stack traces.

    Signed-off-by: Vegard Nossum
    Acked-by: Arjan van de Ven
    Signed-off-by: Ingo Molnar

    Vegard Nossum
     

30 Jan, 2008

4 commits

  • x86: remove unneeded casts

    Signed-off-by: Jan Engelhardt
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Jan Engelhardt
     
  • Right now, we take the stack pointer early during the backtrace path, but
    only calculate bp several functions deep later, making it hard to reconcile
    the stack and bp backtraces (as well as showing several internal backtrace
    functions on the stack with bp based backtracing).

    This patch moves the bp taking to the same place we take the stack pointer;
    sadly this ripples through several layers of the back tracing stack,
    but it's not all that bad in the end I hope.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Arjan van de Ven
     
  • For enhancing the 32 bit EBP based backtracer, I need the capability
    for the backtracer to tell it's customer that an entry is either
    reliable or unreliable, and the backtrace printing code then needs to
    print the unreliable ones slightly different.

    This patch adds the basic capability, the next patch will add a user
    of this capability.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Arjan van de Ven
     
  • Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar

    Thomas Gleixner
     

26 Jan, 2008

1 commit


18 Oct, 2007

1 commit


14 Oct, 2007

1 commit

  • Since the x86 merge, lots of files that referenced their own filenames
    are no longer correct. Rather than keep them up to date, just delete
    them, as they add no real value.

    Additionally:
    - fix up comment formatting in scx200_32.c
    - Remove a credit from myself in setup_64.c from a time when we had no SCM
    - remove longwinded history from tsc_32.c which can be figured out from
    git.

    Signed-off-by: Dave Jones
    Signed-off-by: Linus Torvalds

    Dave Jones
     

11 Oct, 2007

1 commit