Eric Lee / smarc-fsl-linux-kernel

24 Jun, 2016

1 commit

09 Jan, 2015

1 commit

  • a63b03e2d   mutex: Always clear owner field upon mutex_unlock() ... Browse Code »

    Currently if DEBUG_MUTEXES is enabled, the mutex->owner field is only
    cleared iff debug_locks is active. This exposes a race to other users of
    the field where the mutex->owner may be still set to a stale value,
    potentially upsetting mutex_spin_on_owner() among others.

    References: https://bugs.freedesktop.org/show_bug.cgi?id=87955
    Signed-off-by: Chris Wilson
    Signed-off-by: Peter Zijlstra (Intel)
    Acked-by: Davidlohr Bueso
    Cc: Daniel Vetter
    Cc: Linus Torvalds
    Link: http://lkml.kernel.org/r/1420540175-30204-1-git-send-email-chris@chris-wilson.co.uk
    Signed-off-by: Ingo Molnar

    Chris Wilson
     

11 Apr, 2014

1 commit

  • a227960fe   locking/mutex: Fix debug_mutexes ... Browse Code »

    debug_mutex_unlock() would bail when !debug_locks and forgets to
    actually unlock.

    Reported-by: "Michael L. Semon"
    Reported-by: "Kirill A. Shutemov"
    Reported-by: Valdis Kletnieks
    Fixes: 6f008e72cd11 ("locking/mutex: Fix debug checks")
    Tested-by: Dave Jones
    Cc: Jason Low
    Signed-off-by: Peter Zijlstra
    Link: http://lkml.kernel.org/r/20140410141559.GE13658@twins.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

12 Mar, 2014

1 commit

  • 6f008e72c   locking/mutex: Fix debug checks ... Browse Code »

    OK, so commit:

    1d8fe7dc8078 ("locking/mutexes: Unlock the mutex without the wait_lock")

    generates this boot warning when CONFIG_DEBUG_MUTEXES=y:

    WARNING: CPU: 0 PID: 139 at /usr/src/linux-2.6/kernel/locking/mutex-debug.c:82 debug_mutex_unlock+0x155/0x180() DEBUG_LOCKS_WARN_ON(lock->owner != current)

    And that makes sense, because as soon as we release the lock a
    new owner can come in...

    One would think that !__mutex_slowpath_needs_to_unlock()
    implementations suffer the same, but for DEBUG we fall back to
    mutex-null.h which has an unconditional 1 for that.

    The mutex debug code requires the mutex to be unlocked after
    doing the debug checks, otherwise it can find inconsistent
    state.

    Reported-by: Ingo Molnar
    Signed-off-by: Peter Zijlstra
    Cc: jason.low2@hp.com
    Link: http://lkml.kernel.org/r/20140312122442.GB27965@twins.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

17 Dec, 2013

1 commit

  • 91f30a170   mutexes: Give more informative mutex warning in the !lock->owner case ... Browse Code »

    When mutex debugging is enabled and an imbalanced mutex_unlock()
    is called, we get the following, slightly confusing warning:

    [ 364.208284] DEBUG_LOCKS_WARN_ON(lock->owner != current)

    But in that case the warning is due to an imbalanced mutex_unlock() call,
    and the lock->owner is NULL - so the message is misleading.

    So improve the message by testing for this case specifically:

    DEBUG_LOCKS_WARN_ON(!lock->owner)

    Signed-off-by: Liu, Chuansheng
    Signed-off-by: Peter Zijlstra
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Cc: Thomas Gleixner
    Cc: Paul E. McKenney
    Link: http://lkml.kernel.org/r/1386136693.3650.48.camel@cliu38-desktop-build
    [ Improved the changelog, changed the patch to use !lock->owner consistently. ]
    Signed-off-by: Ingo Molnar

    Chuansheng Liu
     

06 Nov, 2013

1 commit