about summary refs log tree commit diff
path: root/src/thread/sem_destroy.c
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2014-08-16 19:15:19 -0400
committerRich Felker <dalias@aerifal.cx>2014-08-16 19:15:19 -0400
commitfffc5cda10e0c5c910b40f7be0d4fa4e15bb3f48 (patch)
tree7fdff6f18f2f03803e6fc7a8a879beafa771c40f /src/thread/sem_destroy.c
parent25d12fc0fc51f1fae0f85b4649a6463eb805aa8f (diff)
downloadmusl-fffc5cda10e0c5c910b40f7be0d4fa4e15bb3f48.tar.gz
musl-fffc5cda10e0c5c910b40f7be0d4fa4e15bb3f48.tar.xz
musl-fffc5cda10e0c5c910b40f7be0d4fa4e15bb3f48.zip
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 'src/thread/sem_destroy.c')
0 files changed, 0 insertions, 0 deletions