On Thu, Aug 25, 2016 at 06:00:19PM -0400, Waiman Long wrote: > On 08/25/2016 02:37 PM, Peter Zijlstra wrote: > >@@ -468,9 +496,12 @@ void __sched mutex_unlock(struct mutex * > > DEBUG_LOCKS_WARN_ON(__mutex_owner(lock) != current); > > #endif > > > >- owner = atomic_long_fetch_and(MUTEX_FLAGS,&lock->owner); > >+ owner = atomic_long_read(&lock->owner); > >+ if (!(owner& MUTEX_FLAG_HANDOFF)) > >+ owner = atomic_long_fetch_and(MUTEX_FLAGS,&lock->owner); > >+ > > if (__owner_flags(owner)) > >- __mutex_unlock_slowpath(lock); > >+ __mutex_unlock_slowpath(lock, owner); > > } > > EXPORT_SYMBOL(mutex_unlock); > > I don't think the race condition is fixed when we don't make sure that lock > handoff only happens from current=>new. The problem is due to the fact that > the MUTEX_FLAG_HANDOFF check in the unlock fastpath isn't serialized by the > wait_lock. As a result, it is possible that the owner is NULL while the > HANDOFF bit is set. Or an optimistic spinner may have stolen the lock in the > interim.
You're right.. I'll try again tomorrow.
