Eric Lee / smarc-fsl-linux-kernel

12 May, 2011

1 commit

  • 449a66fd1   x86: Remove warning and warning_symbol from struct stacktrace_ops ... Browse Code »

    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

  • e8e999cf3   x86, dumpstack: Correct stack dump info when frame pointer is available ... Browse Code »

    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

  • 9c0729dc8   x86: Eliminate bp argument from the stack tracing routines ... Browse Code »

    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

2 commits

  • b0f82b81f   perf: Drop the skip argument from perf_arch_fetch_regs_caller ... Browse Code »

    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

    Frederic Weisbecker
     
  • c9cf4dbb4   x86: Unify dumpstack.h and stacktrace.h ... Browse Code »

    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
     

13 Jan, 2010

1 commit

  • 0fb8ee48d   perf: Drop useless check for ignored frame ... Browse Code »

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

    Frederic Weisbecker
     

17 Dec, 2009

2 commits

  • 06d65bda7   perf events, x86/stacktrace: Fix performance/softlockup by providing a special f… ... Browse Code »

    …rame pointer-only stack walker

    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 <fweisbec@gmail.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Paul Mackerras <paulus@samba.org>
    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 <mingo@elte.hu>

    Frederic Weisbecker
     
  • 61c1917f4   perf events, x86/stacktrace: Make stack walking optional ... Browse Code »

    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
     

02 Jul, 2009

1 commit

  • 0406ca6d8   perf_counter: Ignore the nmi call frames in the x86-64 backtraces ... Browse Code »

    About every callchains recorded with perf record are filled up
    including the internal perfcounter nmi frame:

    perf_callchain
    perf_counter_overflow
    intel_pmu_handle_irq
    perf_counter_nmi_handler
    notifier_call_chain
    atomic_notifier_call_chain
    notify_die
    do_nmi
    nmi

    We want ignore this frame as it's not interesting for
    instrumentation. To solve this, we simply ignore every frames
    from nmi context.

    New example of "perf report -s sym -c" after this patch:

    9.59% [k] search_by_key
    4.88%
    search_by_key
    reiserfs_read_locked_inode
    reiserfs_iget
    reiserfs_lookup
    do_lookup
    __link_path_walk
    path_walk
    do_path_lookup
    user_path_at
    vfs_fstatat
    vfs_lstat
    sys_newlstat
    system_call_fastpath
    __lxstat
    0x406fb1

    3.19%
    search_by_key
    search_by_entry_key
    reiserfs_find_entry
    reiserfs_lookup
    do_lookup
    __link_path_walk
    path_walk
    do_path_lookup
    user_path_at
    vfs_fstatat
    vfs_lstat
    sys_newlstat
    system_call_fastpath
    __lxstat
    0x406fb1
    [...]

    For now this patch only solves the problem in x86-64.

    Signed-off-by: Frederic Weisbecker
    Cc: Peter Zijlstra
    Cc: Mike Galbraith
    Cc: Paul Mackerras
    Cc: Anton Blanchard
    Cc: Arnaldo Carvalho de Melo
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

23 Oct, 2008

2 commits