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>
This commit is contained in:
parent
d025d7858f
commit
24bce50803
|
@ -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);
|
||||
|
||||
|
|
Loading…
Reference in New Issue