From da8d0fc4fa3490f418a438b7e0830f9af312d41f Mon Sep 17 00:00:00 2001 From: Rich Felker Date: Fri, 17 Aug 2012 17:13:53 -0400 Subject: 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. --- src/thread/vmlock.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 src/thread/vmlock.c (limited to 'src/thread/vmlock.c') diff --git a/src/thread/vmlock.c b/src/thread/vmlock.c new file mode 100644 index 00000000..aba9e311 --- /dev/null +++ b/src/thread/vmlock.c @@ -0,0 +1,22 @@ +#include "pthread_impl.h" + +static int vmlock[2]; + +void __vm_lock(int inc) +{ + for (;;) { + int v = vmlock[0]; + if (inc*v < 0) __wait(vmlock, vmlock+1, v, 1); + else if (a_cas(vmlock, v, v+inc)==v) break; + } +} + +void __vm_unlock(void) +{ + int inc = vmlock[0]>0 ? -1 : 1; + if (a_fetch_add(vmlock, inc)==-inc && vmlock[1]) + __wake(vmlock, -1, 1); +} + +weak_alias(__vm_lock, __vm_lock_impl); +weak_alias(__vm_unlock, __vm_unlock_impl); -- cgit v1.2.1