Eric Lee / smarc-fsl-linux-kernel

27 Jul, 2011

1 commit

  • 60063497a   atomic: use <linux/atomic.h> ... Browse Code »

    This allows us to move duplicated code in
    (atomic_inc_not_zero() for now) to

    Signed-off-by: Arun Sharma
    Reviewed-by: Eric Dumazet
    Cc: Ingo Molnar
    Cc: David Miller
    Cc: Eric Dumazet
    Acked-by: Mike Frysinger
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arun Sharma
     

17 Aug, 2010

1 commit

14 Apr, 2009

1 commit

  • 27b19565f   lockdep: warn about lockdep disabling after kernel taint, fix ... Browse Code »

    Impact: build fix for Sparc and s390

    Stephen Rothwell reported that the Sparc build broke:

    In file included from kernel/panic.c:12:
    include/linux/debug_locks.h: In function '__debug_locks_off':
    include/linux/debug_locks.h:15: error: implicit declaration of function 'xchg'

    due to:

    9eeba61: lockdep: warn about lockdep disabling after kernel taint

    There is some inconsistency between architectures about where exactly
    xchg() is defined.

    The traditional place is in system.h but the more logical point for it
    is in atomic.h - where most architectures (especially new ones) have
    it defined. These architecture also still offer it via system.h.

    Some, such as Sparc or s390 only have it in asm/system.h and not available
    via asm/atomic.h at all.

    Use the widest set of headers in debug_locks.h and also include asm/system.h.

    Reported-by: Stephen Rothwell
    Cc: Frederic Weisbecker
    Cc: "David S. Miller"
    Cc: Linus Torvalds
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Ingo Molnar
     

12 Apr, 2009

1 commit

  • 9eeba6138   lockdep: warn about lockdep disabling after kernel taint ... Browse Code »

    Impact: provide useful missing info for developers

    Kernel taint can occur in several situations such as warnings,
    load of prorietary or staging modules, bad page, etc...

    But when such taint happens, a developer might still be working on
    the kernel, expecting that lockdep is still enabled. But a taint
    disables lockdep without ever warning about it.
    Such a kernel behaviour doesn't really help for kernel development.

    This patch adds this missing warning.

    Since the taint is done most of the time after the main message that
    explain the real source issue, it seems safe to warn about it inside
    add_taint() so that it appears at last, without hurting the main
    information.

    v2: Use a generic helper to disable lockdep instead of an
    open coded xchg().

    Signed-off-by: Frederic Weisbecker
    Cc: Peter Zijlstra
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

12 Sep, 2008

1 commit

  • 53b9d87f4   lock debug: sit tight when we are already in a panic ... Browse Code »

    in:

    > http://bugzilla.kernel.org/show_bug.cgi?id=11543

    The panic code called the kexec code which called mutex_trylock() which
    called spin_lock_mutex() which then stupidly went and blurted a load of
    debug stuff because of in_interrupt().

    Keep the lock debug code from escallating an already crappy situation.

    Signed-off-by: Ingo Molnar

    Andrew Morton
     

06 Jul, 2008

1 commit

26 Jan, 2008

1 commit

  • 82a1fcb90   softlockup: automatically detect hung TASK_UNINTERRUPTIBLE tasks ... Browse Code »

    this patch extends the soft-lockup detector to automatically
    detect hung TASK_UNINTERRUPTIBLE tasks. Such hung tasks are
    printed the following way:

    ------------------>
    INFO: task prctl:3042 blocked for more than 120 seconds.
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message
    prctl D fd5e3793 0 3042 2997
    f6050f38 00000046 00000001 fd5e3793 00000009 c06d8264 c06dae80 00000286
    f6050f40 f6050f00 f7d34d90 f7d34fc8 c1e1be80 00000001 f6050000 00000000
    f7e92d00 00000286 f6050f18 c0489d1a f6050f40 00006605 00000000 c0133a5b
    Call Trace:
    [] schedule_timeout+0x6d/0x8b
    [] schedule_timeout_uninterruptible+0x15/0x17
    [] msleep+0x10/0x16
    [] sys_prctl+0x30/0x1e2
    [] sysenter_past_esp+0x5f/0xa5
    =======================
    2 locks held by prctl/3042:
    #0: (&sb->s_type->i_mutex_key#5){--..}, at: [] do_fsync+0x38/0x7a
    #1: (jbd_handle){--..}, at: [] journal_start+0xc7/0xe9
    : CPU hotplug fixes. ]
    [ Andrew Morton : build warning fix. ]

    Signed-off-by: Ingo Molnar
    Signed-off-by: Arjan van de Ven

    Ingo Molnar
     

23 Dec, 2006

1 commit

08 Dec, 2006

1 commit

04 Oct, 2006

1 commit

06 Aug, 2006

1 commit

04 Jul, 2006

1 commit

  • 9a11b49a8   [PATCH] lockdep: better lock debugging ... Browse Code »

    Generic lock debugging:

    - generalized lock debugging framework. For example, a bug in one lock
    subsystem turns off debugging in all lock subsystems.

    - got rid of the caller address passing (__IP__/__IP_DECL__/etc.) from
    the mutex/rtmutex debugging code: it caused way too much prototype
    hackery, and lockdep will give the same information anyway.

    - ability to do silent tests

    - check lock freeing in vfree too.

    - more finegrained debugging options, to allow distributions to
    turn off more expensive debugging features.

    There's no separate 'held mutexes' list anymore - but there's a 'held locks'
    stack within lockdep, which unifies deadlock detection across all lock
    classes. (this is independent of the lockdep validation stuff - lockdep first
    checks whether we are holding a lock already)

    Here are the current debugging options:

    CONFIG_DEBUG_MUTEXES=y
    CONFIG_DEBUG_LOCK_ALLOC=y

    which do:

    config DEBUG_MUTEXES
    bool "Mutex debugging, basic checks"

    config DEBUG_LOCK_ALLOC
    bool "Detect incorrect freeing of live mutexes"

    Signed-off-by: Ingo Molnar
    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar