diff options
author | Rich Felker <dalias@aerifal.cx> | 2016-06-27 15:18:13 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2016-06-27 15:18:13 -0400 |
commit | 384d103d94dba0472a587861f67d7ed6e8955f86 (patch) | |
tree | b113865f16b998f0c8d3d7fe19f33c39785a5e7b /src/thread/pthread_attr_setstacksize.c | |
parent | 6cec7bc57f599f43f4041cec2093e3c9231dbaab (diff) | |
download | musl-384d103d94dba0472a587861f67d7ed6e8955f86.tar.gz musl-384d103d94dba0472a587861f67d7ed6e8955f86.tar.xz musl-384d103d94dba0472a587861f67d7ed6e8955f86.zip |
fix failure to obtain EOWNERDEAD status for process-shared robust mutexes
Linux's documentation (robust-futex-ABI.txt) claims that, when a process dies with a futex on the robust list, bit 30 (0x40000000) is set to indicate the status. however, what actually happens is that bits 0-30 are replaced with the value 0x40000000, i.e. bits 0-29 (containing the old owner tid) are cleared at the same time bit 30 is set. our userspace-side code for robust mutexes was written based on that documentation, assuming that kernel would never produce a futex value of 0x40000000, since the low (owner) bits would always be non-zero. commit d338b506e39b1e2c68366b12be90704c635602ce introduced this assumption explicitly while fixing another bug in how non-recoverable status for robust mutexes was tracked. presumably the tests conducted at that time only checked non-process-shared robust mutexes, which are handled in pthread_exit (which implemented the documented kernel protocol, not the actual one) rather than by the kernel. change pthread_exit robust list processing to match the kernel behavior, clearing bits 0-29 while setting bit 30, and use the value 0x7fffffff instead of 0x40000000 to encode non-recoverable status. the choice of value here is arbitrary; any value with at least one of bits 0-29 set should work just as well,
Diffstat (limited to 'src/thread/pthread_attr_setstacksize.c')
0 files changed, 0 insertions, 0 deletions