From 24bce5080306bd5255cbda3d6b09a29d5515b470 Mon Sep 17 00:00:00 2001 From: Roland Dreier Date: Thu, 21 Jun 2007 11:05:58 -0700 Subject: [PATCH] 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 . Signed-off-by: Roland Dreier --- drivers/infiniband/core/umem.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c index b4aec5103c99..d40652a80151 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; + 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; + schedule_work(&umem->work); + return; + } } else down_write(&mm->mmap_sem);