13 Nov, 2013
1 commit
-
Consider a kernel crash in a module, simulated the following way:
static int my_init(void)
{
char *map = (void *)0x5;
*map = 3;
return 0;
}
module_init(my_init);When we turn off FRAME_POINTERs, the very first instruction in
that function causes a BUG. The problem is that we print IP in
the BUG report using %pB (from printk_address). And %pB
decrements the pointer by one to fix printing addresses of
functions with tail calls.This was added in commit 71f9e59800e5ad4 ("x86, dumpstack: Use
%pB format specifier for stack trace") to fix the call stack
printouts.So instead of correct output:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000005
IP: [] my_init+0x0/0x10 [pb173]We get:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000005
IP: [] 0xffffffffa0151fffTo fix that, we use %pS only for stack addresses printouts (via
newly added printk_stack_address) and %pB for regs->ip (via
printk_address). I.e. we revert to the old behaviour for all
except call stacks. And since from all those reliable is 1, we
remove that parameter from printk_address.Signed-off-by: Jiri Slaby
Cc: Namhyung Kim
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: joe@perches.com
Cc: jirislaby@gmail.com
Link: http://lkml.kernel.org/r/1382706418-8435-1-git-send-email-jslaby@suse.cz
Signed-off-by: Ingo Molnar
01 May, 2013
2 commits
-
Both dump_stack() and show_stack() are currently implemented by each
architecture. show_stack(NULL, NULL) dumps the backtrace for the
current task as does dump_stack(). On some archs, dump_stack() prints
extra information - pid, utsname and so on - in addition to the
backtrace while the two are identical on other archs.The usages in arch-independent code of the two functions indicate
show_stack(NULL, NULL) should print out bare backtrace while
dump_stack() is used for debugging purposes when something went wrong,
so it does make sense to print additional information on the task which
triggered dump_stack().There's no reason to require archs to implement two separate but mostly
identical functions. It leads to unnecessary subtle information.This patch expands the dummy fallback dump_stack() implementation in
lib/dump_stack.c such that it prints out debug information (taken from
x86) and invokes show_stack(NULL, NULL) and drops arch-specific
dump_stack() implementations in all archs except blackfin. Blackfin's
dump_stack() does something wonky that I don't understand.Debug information can be printed separately by calling
dump_stack_print_info() so that arch-specific dump_stack()
implementation can still emit the same debug information. This is used
in blackfin.This patch brings the following behavior changes.
* On some archs, an extra level in backtrace for show_stack() could be
printed. This is because the top frame was determined in
dump_stack() on those archs while generic dump_stack() can't do that
reliably. It can be compensated by inlining dump_stack() but not
sure whether that'd be necessary.* Most archs didn't use to print debug info on dump_stack(). They do
now.An example WARN dump follows.
WARNING: at kernel/workqueue.c:4841 init_workqueues+0x35/0x505()
Hardware name: empty
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.9.0-rc1-work+ #9
0000000000000009 ffff88007c861e08 ffffffff81c614dc ffff88007c861e48
ffffffff8108f50f ffffffff82228240 0000000000000040 ffffffff8234a03c
0000000000000000 0000000000000000 0000000000000000 ffff88007c861e58
Call Trace:
[] dump_stack+0x19/0x1b
[] warn_slowpath_common+0x7f/0xc0
[] warn_slowpath_null+0x1a/0x20
[] init_workqueues+0x35/0x505
...v2: CPU number added to the generic debug info as requested by s390
folks and dropped the s390 specific dump_stack(). This loses %ksp
from the debug message which the maintainers think isn't important
enough to keep the s390-specific dump_stack() implementation.dump_stack_print_info() is moved to kernel/printk.c from
lib/dump_stack.c. Because linkage is per objecct file,
dump_stack_print_info() living in the same lib file as generic
dump_stack() means that archs which implement custom dump_stack()
- at this point, only blackfin - can't use dump_stack_print_info()
as that will bring in the generic version of dump_stack() too. v1
The v1 patch broke build on blackfin due to this issue. The build
breakage was reported by Fengguang Wu.Signed-off-by: Tejun Heo
Acked-by: David S. Miller
Acked-by: Vineet Gupta
Acked-by: Jesper Nilsson
Acked-by: Vineet Gupta
Acked-by: Martin Schwidefsky [s390 bits]
Cc: Heiko Carstens
Cc: Mike Frysinger
Cc: Fengguang Wu
Cc: Bjorn Helgaas
Cc: Sam Ravnborg
Acked-by: Richard Kuo [hexagon bits]
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
There are multiple ways a task can be dumped - explicit call to
dump_stack(), triggering WARN() or BUG(), through sysrq-t and so on.
Most of what gets printed is upto each architecture and the current
state is not particularly pretty. Different pieces of information are
presented differently depending on which path the dump takes and which
architecture it's running on. This is messy for no good reason and
makes it exceedingly difficult to add or modify debug information to
task dumps.In all archs except for s390, there's nothing arch-specific about the
printed debug information. This patchset updates all those archs to use
the same helpers to consistently print out the same debug information.An example WARN dump after this patchset.
WARNING: at kernel/workqueue.c:4841 init_workqueues+0x35/0x505()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.9.0-rc1-work+ #3
Hardware name: empty empty/S3992, BIOS 080011 10/26/2007
0000000000000009 ffff88007c861e08 ffffffff81c614dc ffff88007c861e48
ffffffff8108f500 ffffffff82228240 0000000000000040 ffffffff8234a08e
0000000000000000 0000000000000000 0000000000000000 ffff88007c861e58
Call Trace:
[] dump_stack+0x19/0x1b
[] warn_slowpath_common+0x70/0xa0
[] warn_slowpath_null+0x1a/0x20
[] init_workqueues+0x35/0x505
...And BUG dump.
kernel BUG at kernel/workqueue.c:4841!
invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.9.0-rc1-work+ #7
Hardware name: empty empty/S3992, BIOS 080011 10/26/2007
task: ffff88007c85e040 ti: ffff88007c860000 task.ti: ffff88007c860000
RIP: 0010:[] [] init_workqueues+0x4/0x6
RSP: 0000:ffff88007c861ec8 EFLAGS: 00010246
RAX: ffff88007c861fd8 RBX: ffffffff824466a8 RCX: 0000000000000001
RDX: 0000000000000046 RSI: 0000000000000001 RDI: ffffffff8234a07a
RBP: ffff88007c861ec8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff8234a07a
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff88007dc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff88015f7ff000 CR3: 00000000021f1000 CR4: 00000000000007f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Stack:
ffff88007c861ef8 ffffffff81000312 ffffffff824466a8 ffff88007c85e650
0000000000000003 0000000000000000 ffff88007c861f38 ffffffff82335e5d
ffff88007c862080 ffffffff8223d8c0 ffff88007c862080 ffffffff81c47760
Call Trace:
[] do_one_initcall+0x122/0x170
[] kernel_init_freeable+0x9b/0x1c8
[] ? rest_init+0x140/0x140
[] kernel_init+0xe/0xf0
[] ret_from_fork+0x7c/0xb0
[] ? rest_init+0x140/0x140
...This patchset contains the following seven patches.
0001-x86-don-t-show-trace-beyond-show_stack-NULL-NULL.patch
0002-sparc32-make-show_stack-acquire-fp-if-_ksp-is-not-sp.patch
0003-dump_stack-consolidate-dump_stack-implementations-an.patch
0004-dmi-morph-dmi_dump_ids-into-dmi_format_ids-which-for.patch
0005-dump_stack-implement-arch-specific-hardware-descript.patch
0006-dump_stack-unify-debug-information-printed-by-show_r.patch
0007-arc-print-fatal-signals-reduce-duplicated-informatio.patch0001-0002 update stack dumping functions in x86 and sparc32 in
preparation.0003 makes all arches except blackfin use generic dump_stack().
blackfin still uses the generic helper to print the same info.0004-0005 properly abstract DMI identifier printing in WARN() and
show_regs() so that all dumps print out the information. This enables
show_regs() to use the same debug info message.0006 updates show_regs() of all arches to use a common generic helper
to print debug info.0007 removes somem duplicate information from arc dumps.
While this patchset changes how debug info is printed on some archs,
the printed information is always superset of what used to be there.This patchset makes task dump debug messages consistent and enables
adding more information. Workqueue is scheduled to add worker
information including the workqueue in use and work item specific
description.While this patch touches a lot of archs, it isn't too likely to cause
non-trivial conflicts with arch-specfic changes and would probably be
best to route together either through -mm.x86 is tested but other archs are either only compile tested or not
tested at all. Changes to most archs are generally trivial.This patch:
show_stack(current or NULL, NULL) is used to print the backtrace of the
current task. As trace beyond the function itself isn't of much
interest to anyone, don't show it by determining sp and bp in
show_stack()'s frame and passing them to show_stack_log_lvl().This brings show_stack(NULL, NULL)'s behavior in line with
dump_stack().Signed-off-by: Tejun Heo
Cc: Bjorn Helgaas
Cc: David S. Miller
Cc: Fengguang Wu
Cc: Heiko Carstens
Cc: Jesper Nilsson
Cc: Martin Schwidefsky
Cc: Mike Frysinger
Cc: Vineet Gupta
Cc: Sam Ravnborg
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
21 Jan, 2013
1 commit
-
Fix up all callers as they were before, with make one change: an
unsigned module taints the kernel, but doesn't turn off lockdep.Signed-off-by: Rusty Russell
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
24 May, 2012
1 commit
-
…', 'x86-debug-for-linus' and 'x86-microcode-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull initial trivial x86 stuff from Ingo Molnar.
Various random cleanups and trivial fixes.
* 'x86-asm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86-64: Eliminate dead ia32 syscall handlers* 'x86-cleanups-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/pci-calgary_64.c: Remove obsoleted simple_strtoul() usage
x86: Don't continue booting if we can't load the specified initrd
x86: kernel/dumpstack.c simple_strtoul cleanup
x86: kernel/check.c simple_strtoul cleanup
debug: Add CONFIG_READABLE_ASM
x86: spinlock.h: Remove REG_PTR_MODE* 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/cache_info: Fix setup of l2/l3 ids* 'x86-debug-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86: Avoid double stack traces with show_regs()* 'x86-microcode-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, microcode: microcode_core.c simple_strtoul cleanup
16 May, 2012
1 commit
-
Change kstack_setup() and code_bytes_setup() in kernel/dumpstack.c
to call kstrtoul() instead of calling obsoleted simple_strtoul().Signed-off-by: Shuah Khan
Link: http://lkml.kernel.org/r/1336327084.2897.15.camel@lorien2
Signed-off-by: H. Peter Anvin
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
30 Mar, 2012
1 commit
-
Pull x86 cleanups from Peter Anvin:
"The biggest textual change is the cleanup to use symbolic constants
for x86 trap values.The only *functional* change and the reason for the x86/x32 dependency
is the move of is_ia32_task() into so that it can
be used in other code that needs to understand if a system call comes
from the compat entry point (and therefore uses i386 system call
numbers) or not. One intended user for that is the BPF system call
filter. Moving it out of means we can define it
unconditionally, returning always true on i386."* 'x86-cleanups-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86: Move is_ia32_task to asm/thread_info.h from asm/compat.h
x86: Rename trap_no to trap_nr in thread_struct
x86: Use enum instead of literals for trap values
24 Mar, 2012
1 commit
-
After printing out the first line of a stack backtrace,
print_context_stack() calls print_ftrace_graph_addr() to check
if it's making a graph of function calls, usually not the case.But unfortunate ordering of assignments causes this to oops if
an earlier stack overflow corrupted threadinfo->task. Reorder
to avoid that irritation.( The fact that there was a stack overflow may often be more
interesting than the stack that can now be shown; but
integrating that information with this stacktrace is awkward,
so leave it to overflow reporting. )Signed-off-by: Hugh Dickins
Signed-off-by: Andrew Morton
Cc: Namhyung Kim
Cc: Frederic Weisbecker
Link: http://lkml.kernel.org/r/20120323225648.15DD5A033B@akpm.mtv.corp.google.com
Signed-off-by: Ingo Molnar
13 Mar, 2012
1 commit
-
There are precedences of trap number being referred to as
trap_nr. However thread struct refers trap number as trap_no.
Change it to trap_nr.Also use enum instead of left-over literals for trap values.
This is pure cleanup, no functional change intended.
Suggested-by: Ingo Molnar
Signed-off-by: Srikar Dronamraju
Cc: Linus Torvalds
Cc: Ananth N Mavinakayanahalli
Cc: Jim Keniston
Cc: Linux-mm
Cc: Oleg Nesterov
Cc: Andi Kleen
Cc: Christoph Hellwig
Cc: Steven Rostedt
Cc: Arnaldo Carvalho de Melo
Cc: Masami Hiramatsu
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20120312092555.5379.942.sendpatchset@srdronam.in.ibm.com
[ Fixed the math-emu build ]
Signed-off-by: Ingo Molnar
27 Jan, 2012
1 commit
-
rsyslog will display KERN_EMERG messages on a connected
terminal. However, these messages are useless/undecipherable
for a general user.For example, after a softlockup we get:
Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
kernel:Stack:Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
kernel:Call Trace:Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
kernel:Code: ff ff a8 08 75 25 31 d2 48 8d 86 38 e0 ff ff 48 89
d1 0f 01 c8 0f ae f0 48 8b 86 38 e0 ff ff a8 08 75 08 b1 01 4c 89 e0 0f 01 c9 ea 69 dd ff 4c 29 e8 48 89 c7 e8 0f bc da ff 49 89 c4 49 89This happens because the printk levels for these messages are
incorrect. Only an informational message should be displayed on
a terminal.I modified the printk levels for various messages in the kernel
and tested the output by using the drivers/misc/lkdtm.c kernel
modules (ie, softlockups, panics, hard lockups, etc.) and
confirmed that the console output was still the same and that
the output to the terminals was correct.For example, in the case of a softlockup we now see the much
more informative:Message from syslogd@intel-s3e37-04 at Jan 25 10:18:06 ...
BUG: soft lockup - CPU4 stuck for 60s!instead of the above confusing messages.
AFAICT, the messages no longer have to be KERN_EMERG. In the
most important case of a panic we set console_verbose(). As for
the other less severe cases the correct data is output to the
console and /var/log/messages.Successfully tested by me using the drivers/misc/lkdtm.c module.
Signed-off-by: Prarit Bhargava
Cc: dzickus@redhat.com
Cc: Linus Torvalds
Cc: Andrew Morton
Link: http://lkml.kernel.org/r/1327586134-11926-1-git-send-email-prarit@redhat.com
Signed-off-by: Ingo Molnar
20 May, 2011
1 commit
-
…/gregkh/driver-core-2.6
* 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6: (44 commits)
debugfs: Silence DEBUG_STRICT_USER_COPY_CHECKS=y warning
sysfs: remove "last sysfs file:" line from the oops messages
drivers/base/memory.c: fix warning due to "memory hotplug: Speed up add/remove when blocks are larger than PAGES_PER_SECTION"
memory hotplug: Speed up add/remove when blocks are larger than PAGES_PER_SECTION
SYSFS: Fix erroneous comments for sysfs_update_group().
driver core: remove the driver-model structures from the documentation
driver core: Add the device driver-model structures to kerneldoc
Translated Documentation/email-clients.txt
RAW driver: Remove call to kobject_put().
reboot: disable usermodehelper to prevent fs access
efivars: prevent oops on unload when efi is not enabled
Allow setting of number of raw devices as a module parameter
Introduce CONFIG_GOOGLE_FIRMWARE
driver: Google Memory Console
driver: Google EFI SMI
x86: Better comments for get_bios_ebda()
x86: get_bios_ebda_length()
misc: fix ti-st build issues
params.c: Use new strtobool function to process boolean inputs
debugfs: move to new strtobool
...Fix up trivial conflicts in fs/debugfs/file.c due to the same patch
being applied twice, and an unrelated cleanup nearby.
14 May, 2011
1 commit
-
On some arches (x86, sh, arm, unicore, powerpc) the oops message would
print out the last sysfs file accessed.This was very useful in finding a number of sysfs and driver core bugs
in the 2.5 and early 2.6 development days, but it has been a number of
years since this file has actually helped in debugging anything that
couldn't also be trivially determined from the stack traceback.So it's time to delete the line. This is good as we need all the space
we can get for oops messages at times on consoles.Acked-by: Phil Carmody
Acked-by: Ingo Molnar
Cc: Andrew Morton
Cc: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
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
26 Mar, 2011
1 commit
-
…/git/tip/linux-2.6-tip
* 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
futex: Fix WARN_ON() test for UP
WARN_ON_SMP(): Allow use in if() statements on UP
x86, dumpstack: Use %pB format specifier for stack trace
vsprintf: Introduce %pB format specifier
lockdep: Remove unused 'factor' variable from lockdep_stats_show()
24 Mar, 2011
1 commit
-
Improve noreturn function entries in call traces:
Before:
Call Trace:
[] panic+0x8c/0x18d
[] deep01+0x0/0x38 [test_panic] ] proc_file_write+0x73/0x8d
[] proc_reg_write+0x8d/0xac
[] vfs_write+0xa1/0xc5
[] sys_write+0x45/0x6c
[] system_call_fastpath+0x16/0x1bAfter:
Call Trace:
[] panic+0x8c/0x18d
[] panic_write+0x20/0x20 [test_panic] ] proc_file_write+0x73/0x8d
[] proc_reg_write+0x8d/0xac
[] vfs_write+0xa1/0xc5
[] sys_write+0x45/0x6c
[] system_call_fastpath+0x16/0x1bSigned-off-by: Namhyung Kim
Acked-by: Frederic Weisbecker
Cc: Steven Rostedt
Cc: Linus Torvalds
Cc: Andrew Morton
LKML-Reference:
Signed-off-by: Ingo Molnar
23 Mar, 2011
1 commit
-
The oops=panic cmdline option is not x86 specific, move it to generic code.
Update documentation.Signed-off-by: Olaf Hering
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
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 Feb, 2011
1 commit
-
With no caller left, the function and the DIE_NMIWATCHDOG
enumerator can both go away.Signed-off-by: Jan Beulich
Cc: Peter Zijlstra
Cc: Don Zickus
LKML-Reference:
Signed-off-by: Ingo Molnar
14 Jan, 2011
1 commit
-
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (59 commits)
ACPI / PM: Fix build problems for !CONFIG_ACPI related to NVS rework
ACPI: fix resource check message
ACPI / Battery: Update information on info notification and resume
ACPI: Drop device flag wake_capable
ACPI: Always check if _PRW is present before trying to evaluate it
ACPI / PM: Check status of power resources under mutexes
ACPI / PM: Rename acpi_power_off_device()
ACPI / PM: Drop acpi_power_nocheck
ACPI / PM: Drop acpi_bus_get_power()
Platform / x86: Make fujitsu_laptop use acpi_bus_update_power()
ACPI / Fan: Rework the handling of power resources
ACPI / PM: Register power resource devices as soon as they are needed
ACPI / PM: Register acpi_power_driver early
ACPI / PM: Add function for updating device power state consistently
ACPI / PM: Add function for device power state initialization
ACPI / PM: Introduce __acpi_bus_get_power()
ACPI / PM: Introduce function for refcounting device power resources
ACPI / PM: Add functions for manipulating lists of power resources
ACPI / PM: Prevent acpi_power_get_inferred_state() from making changes
ACPICA: Update version to 20101209
...
12 Jan, 2011
1 commit
-
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying
Reviewed-by: Andi Kleen
Signed-off-by: Len Brown
07 Jan, 2011
1 commit
-
In dump_stack function, bp isn't used anymore, which is introduced by
commit 9c0729dc8062bed96189bd14ac6d4920f3958743. This patch removes bp
completely.Signed-off-by: Rakib Mullick
Cc: Soeren Sandmann
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: H. Peter Anvin
LKML-Reference:
Signed-off-by: Frederic Weisbecker
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
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
26 Mar, 2010
1 commit
-
Support for the PMU's BTS features has been upstreamed in
v2.6.32, but we still have the old and disabled ptrace-BTS,
as Linus noticed it not so long ago.It's buggy: TIF_DEBUGCTLMSR is trampling all over that MSR without
regard for other uses (perf) and doesn't provide the flexibility
needed for perf either.Its users are ptrace-block-step and ptrace-bts, since ptrace-bts
was never used and ptrace-block-step can be implemented using a
much simpler approach.So axe all 3000 lines of it. That includes the *locked_memory*()
APIs in mm/mlock.c as well.Reported-by: Linus Torvalds
Signed-off-by: Peter Zijlstra
Cc: Roland McGrath
Cc: Oleg Nesterov
Cc: Markus Metzger
Cc: Steven Rostedt
Cc: Andrew Morton
LKML-Reference:
Signed-off-by: Ingo Molnar
13 Jan, 2010
1 commit
-
While processing kernel perf callchains, an bad entry can be
considered as a valid stack pointer but not as a kernel address.In this case, we hang in an endless loop. This can happen in an
x86-32 kernel after processing the last entry in a kernel
stacktrace.Just stop the stack frame walking after we encounter an invalid
kernel address.This fixes a hard lockup in x86-32.
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
2 commits
-
…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> -
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
15 Dec, 2009
3 commits
-
Name space cleanup. No functional change.
Signed-off-by: Thomas Gleixner
Acked-by: Peter Zijlstra
Acked-by: David S. Miller
Acked-by: Ingo Molnar
Cc: linux-arch@vger.kernel.org -
Further name space cleanup. No functional change
Signed-off-by: Thomas Gleixner
Acked-by: Peter Zijlstra
Acked-by: David S. Miller
Acked-by: Ingo Molnar
Cc: linux-arch@vger.kernel.org -
The raw_spin* namespace was taken by lockdep for the architecture
specific implementations. raw_spin_* would be the ideal name space for
the spinlocks which are not converted to sleeping locks in preempt-rt.Linus suggested to convert the raw_ to arch_ locks and cleanup the
name space instead of using an artifical name like core_spin,
atomic_spin or whateverNo functional change.
Signed-off-by: Thomas Gleixner
Acked-by: Peter Zijlstra
Acked-by: David S. Miller
Acked-by: Ingo Molnar
Cc: linux-arch@vger.kernel.org
13 Oct, 2009
1 commit
-
The way to obtain a kernel-mode stack pointer from a struct pt_regs in
32-bit mode is "subtle": the stack doesn't actually contain the stack
pointer, but rather the location where it would have been marks the
actual previous stack frame. For clarity, use kernel_stack_pointer()
instead of coding this weirdness explicitly.Furthermore, user_mode() is only valid when the process is known to
not run in V86 mode. Use the safer user_mode_vm() instead.Signed-off-by: H. Peter Anvin
11 Jul, 2009
1 commit
-
Remove duplicated #include in:
arch/x86/kernel/dumpstack.c
Signed-off-by: Huang Weiyi
Signed-off-by: Ingo Molnar
26 Jun, 2009
1 commit
-
This patch introduces a new sysctl:
/proc/sys/kernel/panic_on_io_nmi
which defaults to 0 (off).
When enabled, the kernel panics when the kernel receives an NMI
caused by an IO error.The IO error triggered NMI indicates a serious system
condition, which could result in IO data corruption. Rather
than contiuing, panicing and dumping might be a better choice,
so one can figure out what's causing the IO error.This could be especially important to companies running IO
intensive applications where corruption must be avoided, e.g. a
bank's databases.[ SuSE has been shipping it for a while, it was done at the
request of a large database vendor, for their users. ]Signed-off-by: Kurt Garloff
Signed-off-by: Roberto Angelino
Signed-off-by: Greg Kroah-Hartman
Cc: "Eric W. Biederman"
LKML-Reference:
Signed-off-by: Ingo Molnar
06 Mar, 2009
1 commit
-
Conflicts:
arch/x86/Kconfig
block/blktrace.c
kernel/irq/handle.cSemantic conflict:
kernel/trace/blktrace.cSigned-off-by: Ingo Molnar
19 Feb, 2009
2 commits
-
…nel/git/rostedt/linux-2.6-trace into tracing/function-graph-tracer
-
There is nothing really arch specific of the push and pop functions
used by the function graph tracer. This patch moves them to generic
code.Acked-by: Frederic Weisbecker
Acked-by: Ingo Molnar
Signed-off-by: Steven Rostedt
09 Feb, 2009
1 commit
-
Without frame pointers enabled, the x86 stack traces should not
pretend to be reliable; instead they should just be what they are:
unreliable.The effect of this is that they have a '?' printed in the stacktrace,
to warn the reader that these entries are guesses rather than known
based on more reliable information.Signed-off-by: Arjan van de Ven
Signed-off-by: Ingo Molnar
