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()) > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
