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.

    Linus Torvalds
     

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

    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

    Richard Weinberger
     

26 Mar, 2011

1 commit


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/0x1b

    After:

    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/0x1b

    Signed-off-by: Namhyung Kim
    Acked-by: Frederic Weisbecker
    Cc: Steven Rostedt
    Cc: Linus Torvalds
    Cc: Andrew Morton
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Namhyung Kim
     

23 Mar, 2011

1 commit


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 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

    Jan Beulich
     

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

    Linus Torvalds
     

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

    Huang Ying
     

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

    Rakib Mullick
     

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

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

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

    Peter Zijlstra
     

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

    Frederic Weisbecker
     

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>

    Frederic Weisbecker
     
  • 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
     

15 Dec, 2009

3 commits


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

    H. Peter Anvin
     

11 Jul, 2009

1 commit


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

    Kurt Garloff
     

06 Mar, 2009

1 commit


19 Feb, 2009

2 commits


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

    Arjan van de Ven
     

20 Jan, 2009

1 commit


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

    Steven Rostedt
     

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 Molnar

    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/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(-)

    Neil Horman