linux-stable.git/arch/x86/kernel/dumpstack.c, branch v3.3

bugs, x86: Fix printk levels for panic, softlockups and stack dumps

2012-01-26T20:28:45+00:00

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 89

This 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

Merge branch 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6

2011-05-20T01:24:11+00:00

* '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.

sysfs: remove "last sysfs file:" line from the oops messages

2011-05-13T23:05:51+00:00

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

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

Merge branch 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

2011-03-26T00:52:22+00:00

* '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()

x86, dumpstack: Use %pB format specifier for stack trace

2011-03-24T07:36:10+00:00

Improve noreturn function entries in call traces:

Before:

 Call Trace:
  [] panic+0x8c/0x18d
  [] deep01+0x0/0x38 [test_panic]  <--- bad
  [] proc_file_write+0x73/0x8d
  [] proc_reg_write+0x8d/0xac
  [] vfs_write+0xa1/0xc5
  [] sys_write+0x45/0x6c
  [] system_call_fastpath+0x16/0x1b

After:

 Call Trace:
  [] panic+0x8c/0x18d
  [] panic_write+0x20/0x20 [test_panic] <--- good
  [] proc_file_write+0x73/0x8d
  [] proc_reg_write+0x8d/0xac
  [] vfs_write+0xa1/0xc5
  [] sys_write+0x45/0x6c
  [] system_call_fastpath+0x16/0x1b

Signed-off-by: Namhyung Kim 
Acked-by: Frederic Weisbecker 
Cc: Steven Rostedt 
Cc: Linus Torvalds 
Cc: Andrew Morton 
LKML-Reference: <1300934550-21394-2-git-send-email-namhyung@gmail.com>
Signed-off-by: Ingo Molnar

move x86 specific oops=panic to generic code

2011-03-23T00:44:11+00:00

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

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: Remove die_nmi()

2011-02-18T07:54:05+00:00

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: <4D5D521C0200007800032702@vpn.id2.novell.com>
Signed-off-by: Ingo Molnar

Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6

2011-01-14T04:15:35+00:00

* '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
  ...