From: Steven Rostedt The documented state in both the code and the rt-mutex.txt has a slight incorrect statement. They state that if the owner of the mutex is NULL, and the "mutex has waiters" bit is set that it is an invalid state. This is not true. To synchronize with an owner releasing the mutex, the owner field must have the "mutex has waiters" bit set before trying to grab the lock. This prevents the owner from releasing the lock without going into the slow unlock path. But if the mutex doesn't have an owner, then before the current process grabs the lock, it sets the "mutex has waiters" bit. But in this case it will grab the lock and clear the bit. So the "mutex has waiters" bit and owner == NULL is a transitional state. This patch comments this case. Signed-off-by: Steven Rostedt Acked-by: Thomas Gleixner Signed-off-by: Andrew Morton --- Documentation/rt-mutex.txt | 7 ++++++- kernel/rtmutex.c | 11 +++++++++-- 2 files changed, 15 insertions(+), 3 deletions(-) diff -puN Documentation/rt-mutex.txt~document-futex-pi-design-fix Documentation/rt-mutex.txt --- devel/Documentation/rt-mutex.txt~document-futex-pi-design-fix 2006-05-13 19:37:36.000000000 -0700 +++ devel-akpm/Documentation/rt-mutex.txt 2006-05-13 19:37:36.000000000 -0700 @@ -53,7 +53,7 @@ waiters" state. owner bit1 bit0 NULL 0 0 mutex is free (fast acquire possible) NULL 0 1 invalid state - NULL 1 0 invalid state + NULL 1 0 Transitional state* NULL 1 1 invalid state taskpointer 0 0 mutex is held (fast release possible) taskpointer 0 1 task is pending owner @@ -72,3 +72,8 @@ uninterrupted workflow of high-prio task takes/releases locks that have lower-prio waiters. Without this optimization the higher-prio thread would ping-pong to the lower-prio task [because at unlock time we always assign a new owner]. + +(*) The "mutex has waiters" bit gets set to take the lock. If the lock +doesn't already have an owner, this bit is quickly cleared if there are +no waiters. So this is a transitional state to synchronize with looking +at the owner field of the mutex and the mutex owner releasing the lock. \ No newline at end of file diff -puN kernel/rtmutex.c~document-futex-pi-design-fix kernel/rtmutex.c --- devel/kernel/rtmutex.c~document-futex-pi-design-fix 2006-05-13 19:37:36.000000000 -0700 +++ devel-akpm/kernel/rtmutex.c 2006-05-13 19:37:36.000000000 -0700 @@ -31,7 +31,7 @@ * owner bit1 bit0 * NULL 0 0 lock is free (fast acquire possible) * NULL 0 1 invalid state - * NULL 1 0 invalid state + * NULL 1 0 Transitional State* * NULL 1 1 invalid state * taskpointer 0 0 lock is held (fast release possible) * taskpointer 0 1 task is pending owner @@ -46,9 +46,15 @@ * * The fast atomic compare exchange based acquire and release is only * possible when bit 0 and 1 of lock->owner are 0. + * + * (*) There's a small time where the owner can be NULL and the + * "lock has waiters" bit is set. This can happen when grabbing the lock. + * To prevent a cmpxchg of the owner releasing the lock, we need to set this + * bit before looking at the lock, hence the reason this is a transitional + * state. */ -static void +static vid rt_mutex_set_owner(struct rt_mutex *lock, struct task_struct *owner, unsigned long mask) { @@ -369,6 +375,7 @@ static int try_to_take_rt_mutex(struct r * Note, that this might set lock->owner = * RT_MUTEX_HAS_WAITERS in the case the lock is not contended * any more. This is fixed up when we take the ownership. + * This is the transitional state explained at the top of this file. */ mark_rt_mutex_waiters(lock); _