Robust futex update:

	There is a new robust futex patch on 
http://source.mvista.com/~dsingleton/patch-2.6.14-rt22-rf11
	that fixes three bugs.  One of the bugs was an SMP race condition that 
Dave Carlson had spotted
	and has been gracious enough to test for me.
	
	The bug fixes are:

         1) Down_futex() must call put_task_struct() before the
         call to __down_interruptible so other blocking threads
         can find the owning thread's task struct and block on the futex.

         If put_task_struct is called after down_interruptible returns
         only the first waiter can block through down_interruptible,
         all other waiters can not find the task struct until the
         first waiter is woken.

         2) Robust mutexes only set a timeout if the user requests one.
         This is mainly a performance optimization.  We don't set up
         and tear down a timeout unless the user requested one.

         3) To fix an SMP race condition between wait and wake
         futex_wait_robust() now passes the same parameters and performs
         the same checks for user land race as futex_wait().

         This change makes the code simpler and more similar to 
futex_wait.

         Futex_wait passes in the value that that glibc got from the
         pthread_mutex at compare and xchange time.  Futex_wait_robust 
now
         does the same check, after aquiring the correct locks, to see if
         the lock in user space has changed since entering the kernel.

         (There is a corresponding patch for glibc to pass the lock
         value into futex_wait_robust.)

         Futex wake also has a new race condition check for the following
         SMP race scenario:

         Thread A gets the pthread_mutex via the fast path and does not
         enter the kernel.

         Thread B tries to lock the same pthread mutex and discovers its
         already locked.  It sets the waiters flag in the lock and enters
         the kernel to block on the futex.

         Thread A releases the lock and sees the waiters flag. Thread A
         enters the kernel to unlock the futex and wake the waiters
         before thread B can get into the kernel and lock the futex
         on behalf of thread A.

         Thread A discovers that it does not own the lock and returns
         EINVAL erroneously.

         With this fix Thread A now locks the futex and unlocks the
         robust semaphore protecting the futex and the mmap_sem
         protecting the vma and goes around the loop one more time
         to allow the waiters a chance to actually block before the
         wake occurs.


David 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/