[Bug nptl/21083] New: robust timed lock may leave other waiters no chance to wake up

["ma.jiang at zte dot com.cn" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=21083

            Bug ID: 21083
           Summary: robust timed lock may leave other waiters no chance to
                    wake up
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: ma.jiang at zte dot com.cn
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 9772
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9772&action=edit
patch to fix the bug

Hi all,
  I found the bug in robust timed mutex still existed in the latest glibc
source, when porting some local patches to the newest glibc release.
  Provided there were 3 threads A，B and C， all of which were trying to
manipulate the same robust mutex. See the following illustration.

A:                       B:                            C:
pthread_mutex_lock(m);
                         pthread_mutex_timedlock(m);
                                                       pthread_mutex_lock(m);   
pthread_mutex_unlock(m);
pthread_mutex_lock(m);

pthread_mutex_unlock(m);

First, A locked m. Then B and C try to lock m, and both get traped(wait in
kernel). 
A unlock m, wake up B and clear the FUTEX_WAITER flag.
After B wake up(and have not do anything yet), A preempt B and lock m again. At
this time， A will not add FUTEX_WAITER flag to m as it does not know whether
there are other waiters.
B continue to run, it call gettimeofday and find the time is out. So, it just
return ETIMEOUT without trying to set  FUTEX_WAITER flag.
A unlock m , and do not do the wake syscall as there is no FUTEX_WAITER.
C get stuck in kernel forever.

The core logic of this problem is that pthread_mutex_timedlock should set the
FUTEX_WAITER flag before check timeout. So, the fix to the bug is very simple.
We just need to move the code block which set the FUTEX_WAITER flag forward. I
have created a patch to fix(see attachment) , is it ok for trunk?

-- 
You are receiving this mail because:
You are on the CC list for the bug.