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.

1 files changed, 22 insertions, 0 deletions

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);