20 Jun, 2012
1 commit
-
Printing the list of loaded modules is really unrelated to what
this function is about, and is particularly unnecessary in the
context of the SysRQ key handling (gets printed so far over and
over).It should really be the caller of the function to decide whether
this piece of information is useful (and to avoid redundantly
printing it).Signed-off-by: Jan Beulich
Link: http://lkml.kernel.org/r/4FDF21A4020000780008A67F@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar
06 Jun, 2012
1 commit
-
Use a more current logging style:
- Bare printks should have a KERN_ for consistency's sake
- Add pr_fmt where appropriate
- Neaten some macro definitions
- Convert some Ok output to OK
- Use "%s: ", __func__ in pr_fmt for summit
- Convert some printks to pr_Message output is not identical in all cases.
Signed-off-by: Joe Perches
Cc: levinsasha928@gmail.com
Link: http://lkml.kernel.org/r/1337655007.24226.10.camel@joe2Laptop
[ merged two similar patches, tidied up the changelog ]
Signed-off-by: Ingo Molnar
09 May, 2012
1 commit
-
What was called show_registers() so far already showed a stack
trace for kernel faults, and kernel_stack_pointer() isn't even
valid to be used for faults from user mode, hence it was
pointless for show_regs() to call show_trace() after
show_registers().Simply rename show_registers() to show_regs() and eliminate
the old definition.Signed-off-by: Jan Beulich
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Arjan van de Ven
Cc: Frederic Weisbecker
Link: http://lkml.kernel.org/r/4FAA3D3902000078000826E1@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar
08 Mar, 2012
1 commit
-
While for a user mode register dump it may be reasonable to skip
those (albeit x86-64 doesn't do so), for kernel mode dumps these
should be printed to make sure all information possibly
necessary for analysis is available.Signed-off-by: Jan Beulich
Link: http://lkml.kernel.org/r/4F58889202000078000770E7@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar
20 Dec, 2011
1 commit
-
When printing the code bytes in show_registers(), the markers around the
byte at the fault address could make the printk() format string look
like a valid log level and facility code. This would prevent this byte
from being printed and result in a spurious newline:[ 7555.765589] Code: 8b 32 e9 94 00 00 00 81 7d 00 ff 00 00 00 0f 87 96 00 00 00 48 8b 83 c0 00 00 00 44 89 e2 44 89 e6 48 89 df 48 8b 80 d8 02 00 00
[ 7555.765683] 8b 48 28 48 89 d0 81 e2 ff 0f 00 00 48 c1 e8 0c 48 c1 e0 04Add KERN_CONT where needed, and elsewhere in show_registers() for
consistency.Signed-off-by: Clemens Ladisch
Link: http://lkml.kernel.org/r/4EEFA7AE.9020407@ladisch.de
Signed-off-by: H. Peter Anvin
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/0x10after:
[ 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 fixesSigned-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
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 taskIn 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
24 Oct, 2010
1 commit
-
The stack output currently looks like this:
7fffffffffffffff 0000000a00000000 ffffffff81093341 0000000000000046
ffff88003a545fd8 0000000000000000 0000000000000000 00007fffa39769c0
ffff88003e403f58 ffffffff8102fc4c ffff88003e403f58 ffff88003e403f78The superfluous are caused by recent printk KERN_CONT
change. is now ignored in printk unless some text follows
the level and even then it still has to be the first in the
format message.Note that the log_lvl parameter is now completely ignored in
show_stack_log_lvl and the stack is dumped with the default
level (like for quite some time already). It behaves the same as
the rest of the dump, function traces are dumped in the very
same manner. Only Code and maybe some lines are printed with
EMERG level.Unfortunately I see no way how to fix this conceptually to have
the whole oops/BUG/panic output with the same level, so this
removed only the superfluous characters for the time being.Just for illustration:
Process kworker/0:0 (pid: 0, threadinfo ffff88003c8a6000, task ffff88003c85c100)
Stack:
ffffffff818022c0 0000000a00000001 0000000000000001 0000000000000046
ffff88003c8a7fd8 0000000000000001 ffff88003c8a7e58 0000000000000000
ffff88003e503f48 ffffffff8102fc4c ffff88003e503f48 ffff88003e503f68
Call Trace:
[] ? call_softirq+0x1c/0x30 ...
Code: 00 01 00 00 65 8b 04 25 80 c5 00 00 c7 45 ...Signed-off-by: Jiri Slaby
Cc: jirislaby@gmail.com
Cc: Linus Torvalds
Cc: Andrew Morton
LKML-Reference:
Signed-off-by: Ingo Molnar
09 Jun, 2010
1 commit
-
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.hAlthough 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
13 Jan, 2010
1 commit
-
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
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
26 Nov, 2009
1 commit
-
Make the initialization more readable, plus tidy up a few small
visual details as well.No change in functionality.
LKML-Reference:
Signed-off-by: Ingo Molnar
24 Sep, 2009
1 commit
-
* remove asm/atomic.h inclusion from linux/utsname.h --
not needed after kref conversion
* remove linux/utsname.h inclusion from files which do not need itNOTE: it looks like fs/binfmt_elf.c do not need utsname.h, however
due to some personality stuff it _is_ needed -- cowardly leave ELF-related
headers and files alone.Signed-off-by: Alexey Dobriyan
Signed-off-by: Linus Torvalds
02 Jul, 2009
1 commit
-
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
nmiWe 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
0x406fb13.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
03 Dec, 2008
1 commit
-
Impact: better dumpstack output
I noticed in my crash dumps and even in the stack tracer that a
lot of functions listed in the stack trace are simply
return_to_handler which is ftrace graphs way to insert its own
call into the return of a function.But we lose out where the actually function was called from.
This patch adds in hooks to the dumpstack mechanism that detects
this and finds the real function to print. Both are printed to
let the user know that a hook is still in place.This does give a funny side effect in the stack tracer output:
Depth Size Location (80 entries)
----- ---- --------
0) 4144 48 save_stack_trace+0x2f/0x4d
1) 4096 128 ftrace_call+0x5/0x2b
2) 3968 16 mempool_alloc_slab+0x16/0x18
3) 3952 384 return_to_handler+0x0/0x73
4) 3568 -240 stack_trace_call+0x11d/0x209
5) 3808 144 return_to_handler+0x0/0x73
6) 3664 -128 mempool_alloc+0x4d/0xfe
7) 3792 128 return_to_handler+0x0/0x73
8) 3664 -32 scsi_sg_alloc+0x48/0x4a [scsi_mod]As you can see, the real functions are now negative. This is due
to them not being found inside the stack.Signed-off-by: Steven Rostedt
Signed-off-by: Ingo Molnar
28 Oct, 2008
1 commit
-
Impact: cleanup
As promised, now that dumpstack_32 and dumpstack_64 have so many bits
in common, we should merge the in-sync bits into a common file, to
prevent them from diverging again.This patch removes bits which are common between dumpstack_32.c and
dumpstack_64.c and places them in a common dumpstack.c which is built
for both 32 and 64 bit arches.Signed-off-by: Neil Horman
Acked-by: Alexander van Heukelum
Signed-off-by: Ingo MolnarMakefile | 2
arch/x86/kernel/Makefile | 2
arch/x86/kernel/Makefile | 2
arch/x86/kernel/Makefile | 2
arch/x86/kernel/Makefile | 2
arch/x86/kernel/Makefile | 2
arch/x86/kernel/dumpstack.c | 319 +++++++++++++++++++++++++++++++++++++++++
arch/x86/kernel/dumpstack.h | 39 +++++
arch/x86/kernel/dumpstack_32.c | 294 -------------------------------------
arch/x86/kernel/dumpstack_64.c | 285 ------------------------------------
5 files changed, 363 insertions(+), 576 deletions(-)
22 Oct, 2008
7 commits
-
Make i386's die() equal to x86_64's version.
Whitespace-only changes on x86_64, to make it equal to i386's
version. (user_mode and user_mode_vm are equal on x86_64.)Signed-off-by: Alexander van Heukelum
Acked-by: Neil Horman
Signed-off-by: Ingo Molnar -
Use oops_begin and oops_end in die_nmi.
Whitespace-only changes on x86_64, to make it equal to i386's
version.Signed-off-by: Alexander van Heukelum
Acked-by: Neil Horman
Signed-off-by: Ingo Molnar -
oops_begin/oops_end should always be used in pairs. On x86_64
oops_begin increments die_nest_count, and oops_end decrements
die_nest_count. Doing this makes oops_begin and oops_end equal
to the x86_64 versions.Signed-off-by: Alexander van Heukelum
Acked-by: Neil Horman
Signed-off-by: Ingo Molnar -
Always call oops_exit from oops_end, even if signr==0.
Also, move add_taint(TAINT_DIE) from __die to oops_end
on x86_64 and interchange two lines to make oops_end
more similar to the i386-version.Signed-off-by: Alexander van Heukelum
Acked-by: Neil Horman
Signed-off-by: Ingo Molnar -
Change oops_end such that signr=0 signals that do_exit
is not to be called.Currently, each use of __die is soon followed by a call
to oops_end and 'regs' is set to NULL if oops_end is expected
not to call do_exit. Change all such pairs to set signr=0
instead. On x86_64 oops_end is used 'bare' in die_nmi; use
signr=0 instead of regs=NULL there, too.Signed-off-by: Alexander van Heukelum
Acked-by: Neil Horman
Signed-off-by: Ingo Molnar -
crash_kexec should not be called with console_sem held. Move
the call before bust_spinlocks(0) in oops_end to avoid the
problem.Signed-off-by: Alexander van Heukelum
Acked-by: "Neil Horman"
Signed-off-by: Ingo Molnar -
There's a corner case in 32 bit x86 kdump at the moment. When the box
panics via nmi, we call bust_spinlocks(1) to disable sensitivity to the
console_sem (allowing us to print to the console in all cases), but we don't
call crash_kexec, until after we call bust_spinlocks(0), which re-enables
console_sem sensitivity.The result is that, if we get an nmi while the console_sem is held and
kdump is configured, and we try to print something to the console during
kdump shutdown (which we often do) we deadlock the box. The fix is to
simply do what 64 bit die_nmi does which is to not call bust_spinlocks(0)
until after we call crash_kexec.Patch below tested successfully by me.
Signed-off-by: Neil Horman
Signed-off-by: Ingo Molnar
17 Oct, 2008
1 commit
-
Print the name of the last-accessed sysfs file when we oops, to help track
down oopses which occur in sysfs store/read handlers. Because these oopses
tend to not leave any trace of the offending code in the stack traces.Cc: Kay Sievers
Cc: Mathieu Desnoyers
Signed-off-by: Andrew Morton
Signed-off-by: Greg Kroah-Hartman
13 Oct, 2008
8 commits
-
- define STACKSLOTS_PER_LINE and use it
- define get_bp macro to hide the %%ebp/%%rbp difference
- i386: check task==NULL in dump_trace, like x86_64
- i386: show_trace(NULL, ...) uses current automatically
- x86_64: use [#%d] for die_counter, like i386
- whitespace and commentsSigned-off-by: Alexander van Heukelum
Signed-off-by: Ingo Molnar -
- make kstack= and early_param
- add oops=panic, setting panic_on_oopsSigned-off-by: Alexander van Heukelum
Signed-off-by: Ingo Molnar -
- x86: Write log_lvl strings if available
- start raw stack dumps on new line
- i386: Remove extra indentation for raw stack dumpsSigned-off-by: Alexander van Heukelum
Signed-off-by: Ingo Molnar -
- i386 and x86_64: always printk the 'data' parameter
- i386: announce stack switch (irq -> normal)
- i386: check if there is a stack switch before announcing itThere is a warning that 'context' might come out corrupt in early
boot. If this is true it should be fixed, not worked around.Signed-off-by: Alexander van Heukelum
Signed-off-by: Ingo Molnar -
- Add "end" parameter to valid_stack_ptr and print_context_stack
- use sizeof(long) as the size of a word on the stackSigned-off-by: Alexander van Heukelum
Signed-off-by: Ingo Molnar -
- x86_64: use %p to print an address
- make i386-version the same as the aboveThe result should be the same on x86_64; on i386 the
output only changes if CONFIG_KALLSYMS is turned off,
in which case the address is printed twice.Signed-off-by: Alexander van Heukelum
Signed-off-by: Ingo Molnar -
For some reason die_nmi is still defined in traps.c for
i386, but is found in dumpstack_64.c for x86_64. Move it
to dumpstack_32.cSigned-off-by: Alexander van Heukelum
Signed-off-by: Ingo Molnar -
The dumpstack code is logically quite independent from the
hardware traps. Split it out into its own file.Signed-off-by: Alexander van Heukelum
Signed-off-by: Ingo Molnar
