On Thu, Aug 25, 2016 at 06:00:19PM -0400, Waiman Long wrote:
On 08/25/2016 02:37 PM, Peter Zijlstra wrote:You're right.. I'll try again tomorrow.
@@ -468,9 +496,12 @@ void __sched mutex_unlock(struct mutex *I don't think the race condition is fixed when we don't make sure that lock
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);
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.