Re: robust futex heap support patch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 


On Dec 5, 2005, at 2:30 PM, Esben Nielsen wrote:

I'm currently trying to close a race condition between futex_wait_robust
and futex_wake_robust that Dave Carlson is seeing on his SMP system.

The scenario is as follows:
Thread A locks an pthread_mutex via the fast path and does not enter the kernel.
Thread B tries to lock the lock and sees it is already locked. Thread B sets the waiters flag in the lock and enters the kernel to lock the lock on behalf of 
thread A and then block on the mutex waiting for it's release.

Thread A unlocks the lock and sees the waiters flag set.  Thread A gets
to the futex_wake_robust before Thread B can get to futex_wait_robust.
Thread A sees that it does not own the lock in the kernel and was returning EINVAL.
patch-2.6.14-rt21-rf8 was a preliminary patch for Dave Carlson to try and get more information about the race condition. ( rf8 and rf9 are still returning EAGAIN from thread B trying to do the futex_wait_robust and the library should be retrying with EAGAIN, but it currently isn't).
When I get the race condition closed I'll post the patch and notify everyone on lkml 
and the robustmutexes mailing lists.

David




Hi,
 I got a little time to look at your current patch (2.6.14-rt21-rf8).
I noticed a problem in futex_wake_robust(). You have a "goto retry" to
solve the following situation:

  Task A                             Task B
      takes futex in userspace
                                     Tries to take mutex and sets the
                                     waiting bit in user space
      releases futex, notices task B
      calls kernel and enters
      futex_wake_robust()

    retry:
      if not owner in rt_mutex
         goto retry;
                                     Calls kernel
                                     Makes A owner in rt_mutex
                                     blocks
       Leaves retry-loop and
       completes the futex wake
       operation as normally.
However, if Task A is RT on a UP machine it will go on in the retry loop 
forever. Task B will never get the CPU to complete it's kernel-call.

You have probably by manipulating the userspace flag from within the
rt_mutex code :-(

Esben


On Fri, 25 Nov 2005, david singleton wrote:


There is a new patch, patch-2.6.14-rt15-rf1,  that adds support for
robust and priority inheriting
pthread_mutexes on the 'heap'.

The previous patches only supported either file based pthread_mutexes
or mmapped anonymous memory based pthread_mutexes.  This patch allows
pthread_mutexes
to be 'malloc'ed while using the PTHREAD_MUTEX_ROBUST_NP attribute
or PTHREAD_PRIO_INHERIT attribute.

The patch can be found at:

http://source.mvista.com/~dsingleton

David

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





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux