binder_alloc: prevent possible OOO mutex acquisition

Fix possible deadlock:
1. In most binder_alloc paths, the binder_alloc mutex is acquired before
calling into mm functions which can acquire the mmap_sem

2. During address space teardown, the mm system acquires mmap_sem which
can call into binder_alloc_vma_close which acquired the binder_alloc
mutex

Since they are acquired in opposite order, a thread doing #1 can
deadlock with a thread doing #2. There are no known cases where
this was seen, but it is possible.

The binder alloc mutex doesn't need to be acquired in the vma_close
path.

Bug: 36524239
Test: tested manually
Change-Id: I40b077fc3bc01e37b389043f2966257797ee9ce5
Signed-off-by: Todd Kjos <tkjos@google.com>

drivers/android/binder_alloc.c

@@ -683,10 +683,9 @@ int binder_alloc_get_allocated_count(struct binder_alloc *alloc)
 
 void binder_alloc_vma_close(struct binder_alloc *alloc)
 {
-	mutex_lock(&alloc->mutex);
-	alloc->vma = NULL;
-	alloc->vma_vm_mm = NULL;
-	mutex_unlock(&alloc->mutex);
+	WRITE_ONCE(alloc->vma, NULL);
+	WRITE_ONCE(alloc->vma_vm_mm, NULL);
+	barrier();
 }
 
 void binder_alloc_init(struct binder_alloc *alloc)