diff options
author | Rich Felker <dalias@aerifal.cx> | 2014-08-16 19:15:19 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2014-08-16 19:15:19 -0400 |
commit | fffc5cda10e0c5c910b40f7be0d4fa4e15bb3f48 (patch) | |
tree | 7fdff6f18f2f03803e6fc7a8a879beafa771c40f /include/sys | |
parent | 25d12fc0fc51f1fae0f85b4649a6463eb805aa8f (diff) | |
download | musl-fffc5cda10e0c5c910b40f7be0d4fa4e15bb3f48.tar.gz |
fix false ownership of mutexes due to tid reuse, using robust list
per the resolution of Austin Group issue 755, the POSIX requirement
that ownership be enforced for recursive and error-checking mutexes
does not allow a random new thread to acquire ownership of an orphaned
mutex just because it happened to be assigned the same tid as the
original owner that exited with the mutex locked.
one possible fix for this issue would be to disallow the kernel thread
to terminate when it exited with mutexes held, permanently reserving
the tid against reuse. however, this does not solve the problem for
process-shared mutexes where lifetime cannot be controlled, so it was
not used.
the alternate approach I've taken is to reuse the robust mutex system
for non-robust recursive and error-checking mutexes. when a thread
exits, the kernel (or the new userspace robust-list code added in
commit b092f1c5fa9c048e12d002c7b972df5ecbe96d1d) will set the
owner-died bit for these orphaned mutexes, but since the mutex-type is
not robust, pthread_mutex_trylock will not allow a new owner to
acquire them. instead, they remain in a state of being permanently
locked, as desired.
Diffstat (limited to 'include/sys')
0 files changed, 0 insertions, 0 deletions