This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

            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
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 9772
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:


First, A locked m. Then B and C try to lock m, and both get traped(wait in
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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]