summaryrefslogtreecommitdiff
path: root/src/stdio/ftrylockfile.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/stdio/ftrylockfile.c
parent25d12fc0fc51f1fae0f85b4649a6463eb805aa8f (diff)
downloadmusl-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 'src/stdio/ftrylockfile.c')
0 files changed, 0 insertions, 0 deletions