race condition fix: block all signals before decrementing thread count
authorRich Felker <dalias@aerifal.cx>
Sat, 19 Feb 2011 16:04:36 +0000 (11:04 -0500)
committerRich Felker <dalias@aerifal.cx>
Sat, 19 Feb 2011 16:04:36 +0000 (11:04 -0500)
commit19eb13b9a4cf2f787f60b6e2a6d26a6cd7d3ffd2
treec02fa747b1ad7370b689af34f15139cb62fa9863
parenta49c119276742d7d212fb88f83a8f559ca549e72
race condition fix: block all signals before decrementing thread count

the existence of a (kernelspace) thread must never have observable
effects after the thread count is decremented. if signals are not
blocked, it could end up handling the signal for rsyscall and
contributing towards the count of threads which have changed ids,
causing a thread to be missed. this could lead to one thread retaining
unwanted privilege level.

this change may also address other subtle race conditions in
application code that uses signals.
src/thread/i386/__unmapself.s
src/thread/pthread_create.c
src/thread/x86_64/__unmapself.s