|author||Rich Felker <email@example.com>||2012-08-17 17:13:53 -0400|
|committer||Rich Felker <firstname.lastname@example.org>||2012-08-17 17:13:53 -0400|
fix extremely rare but dangerous race condition in robust mutexes
if new shared mappings of files/devices/shared memory can be made between the time a robust mutex is unlocked and its subsequent removal from the pending slot in the robustlist header, the kernel can inadvertently corrupt data in the newly-mapped pages when the process terminates. i am fixing the bug by using the same global vm lock mechanism that was used to fix the race condition with unmapping barriers after pthread_barrier_wait returns.
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions