From: Roland Dreier <rolandd@cisco.com>
Date: Thu, 21 Jun 2007 18:05:58 +0000 (-0700)
Subject: IB/umem: Fix possible hang on process exit
X-Git-Tag: v2.6.22-rc6~38^2~4
X-Git-Url: https://err.no/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=24bce5080306bd5255cbda3d6b09a29d5515b470;p=linux-2.6

IB/umem: Fix possible hang on process exit

If ib_umem_release() is called after ib_uverbs_close() sets context->closing,
then a process can get stuck in a D state, because the code boils down to

	if (down_write_trylock(&mm->mmap_sem))
		down_write(&mm->mmap_sem);

which is obviously a stupid instant deadlock.  Fix the code so that we
only try to take the lock once.

This bug was introduced in commit f7c6a7b5 ("IB/uverbs: Export
ib_umem_get()/ib_umem_release() to modules") which fortunately never
made it into a release, and was reported by Pete Wyckoff <pw@osc.edu>.

Signed-off-by: Roland Dreier <rolandd@cisco.com>
---

diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index b4aec5103c..d40652a801 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -225,13 +225,15 @@ void ib_umem_release(struct ib_umem *umem)
 	 * up here and not be able to take the mmap_sem.  In that case
 	 * we defer the vm_locked accounting to the system workqueue.
 	 */
-	if (context->closing && !down_write_trylock(&mm->mmap_sem)) {
-		INIT_WORK(&umem->work, ib_umem_account);
-		umem->mm   = mm;
-		umem->diff = diff;
-
-		schedule_work(&umem->work);
-		return;
+	if (context->closing) {
+		if (!down_write_trylock(&mm->mmap_sem)) {
+			INIT_WORK(&umem->work, ib_umem_account);
+			umem->mm   = mm;
+			umem->diff = diff;
+
+			schedule_work(&umem->work);
+			return;
+		}
 	} else
 		down_write(&mm->mmap_sem);