* Waiman Long <longman@xxxxxxxxxx> wrote: > On 11/30/23 15:48, Jann Horn wrote: > > I have seen several cases of attempts to use mutex_unlock() to release an > > object such that the object can then be freed by another task. > > My understanding is that this is not safe because mutex_unlock(), in the > > MUTEX_FLAG_WAITERS && !MUTEX_FLAG_HANDOFF case, accesses the mutex > > structure after having marked it as unlocked; so mutex_unlock() requires > > its caller to ensure that the mutex stays alive until mutex_unlock() > > returns. > > > > If MUTEX_FLAG_WAITERS is set and there are real waiters, those waiters > > have to keep the mutex alive, I think; but we could have a spurious > > MUTEX_FLAG_WAITERS left if an interruptible/killable waiter bailed > > between the points where __mutex_unlock_slowpath() did the cmpxchg > > reading the flags and where it acquired the wait_lock. > > Could you clarify under what condition a concurrent task can decide to free > the object holding the mutex? Is it !mutex_is_locked() or after a > mutex_lock()/mutex_unlock sequence? > > mutex_is_locked() will return true if the mutex has waiter even if it is > currently free. I believe the correct condition is what the changelog already says: "until mutex_unlock() returns". What happens within mutex_unlock() is kernel implementation specific and once a caller has called mutex_unlock(), the mutex must remain alive until it returns. No other call can substitute for this: neither mutex_is_locked(), nor some sort of mutex_lock()+mutex_unlock() sequence. Thanks, Ingo
