This is the mail archive of the
mailing list for the glibc project.
[Bug nptl/21083] New: robust timed lock may leave other waiters no chance to wake up
- From: "ma.jiang at zte dot com.cn" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 25 Jan 2017 10:16:02 +0000
- Subject: [Bug nptl/21083] New: robust timed lock may leave other waiters no chance to wake up
- Auto-submitted: auto-generated
Bug ID: 21083
Summary: robust timed lock may leave other waiters no chance to
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
patch to fix the bug
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.