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:0.065 / U:0.736 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site