lkml.org 
[lkml]   [2014]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [tip:core/locking] locking/mutexes: Unlock the mutex without the wait_lock
    From
    Date
    On Wed, 2014-03-12 at 13:24 +0100, Peter Zijlstra wrote:
    > On Tue, Mar 11, 2014 at 05:41:23AM -0700, tip-bot for Jason Low wrote:
    > > kernel/locking/mutex.c | 8 ++++----
    > > 1 file changed, 4 insertions(+), 4 deletions(-)
    > >
    > > diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
    > > index 82dad2c..dc3d6f2 100644
    > > --- a/kernel/locking/mutex.c
    > > +++ b/kernel/locking/mutex.c
    > > @@ -671,10 +671,6 @@ __mutex_unlock_common_slowpath(atomic_t *lock_count, int nested)
    > > struct mutex *lock = container_of(lock_count, struct mutex, count);
    > > unsigned long flags;
    > >
    > > - spin_lock_mutex(&lock->wait_lock, flags);
    > > - mutex_release(&lock->dep_map, nested, _RET_IP_);
    > > - debug_mutex_unlock(lock);
    > > -

    With the latest patch, perhaps it may be helpful to also add to the
    comment below, mentioning that it doesn't unlock here for debug mutexes
    since the following debug_mutex_unlock() would handle the unlocking
    instead.

    > > /*
    > > * some architectures leave the lock unlocked in the fastpath failure
    > > * case, others need to leave it locked. In the later case we have to
    > > @@ -683,6 +679,10 @@ __mutex_unlock_common_slowpath(atomic_t *lock_count, int nested)
    > > if (__mutex_slowpath_needs_to_unlock())
    > >



    \
     
     \ /
      Last update: 2014-03-12 20:21    [W:3.115 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site