diff options
| author | Rich Felker <dalias@aerifal.cx> | 2020-11-20 10:43:20 -0500 |
|---|---|---|
| committer | Rich Felker <dalias@aerifal.cx> | 2020-11-20 10:43:20 -0500 |
| commit | debbddf7c86dfe7fb2f44f057123ccfd950ff555 (patch) | |
| tree | bfb268bc3a66503da366658c2f9ef6d0c86b6ebd /compat/time32/utimes_time32.c | |
| parent | 3ab2a4e02682df1382955071919d8aa3c3ec40d4 (diff) | |
| download | musl-debbddf7c86dfe7fb2f44f057123ccfd950ff555.tar.gz musl-debbddf7c86dfe7fb2f44f057123ccfd950ff555.tar.xz musl-debbddf7c86dfe7fb2f44f057123ccfd950ff555.zip | |
fix regression in pthread_exit
commit d26e0774a59bb7245b205bc8e7d8b35cc2037095 moved the detach state transition at exit before the thread list lock was taken. this inadvertently allowed pthread_join to race to take the thread list lock first, and proceed with unmapping of the exiting thread's memory. we could fix this by just revering the offending commit and instead performing __vm_wait unconditionally before taking the thread list lock, but that may be costly. instead, bring back the old DT_EXITING vs DT_EXITED state distinction that was removed in commit 8f11e6127fe93093f81a52b15bb1537edc3fc8af, and don't transition to DT_EXITED (a value of 0, which is what pthread_join waits for) until after the lock has been taken.
Diffstat (limited to 'compat/time32/utimes_time32.c')
0 files changed, 0 insertions, 0 deletions