[openib-general] [PATCH] Optimize cma_process_remove()

[Krishna Kumar]

Hi Sean,

> I believe that this has the same issue.  If a user tries to destroy an 
> rdma_cm_id, it will remove itself from the "device list".  (This is why 
the ID's 
> are moved to a new list, so that the removal still works.)  In the code 
above, 
> destroy thread(s) will remove ID(s) from the remove_list while we're 
trying to 
> walk it.

Thanks for the explanation. So a list_del_init() would be the best
thing to do. Another option is to add a remove_list to rdma_id_private
by which this entry could be added to a local remove_list and traversed
without holding a lock, but it doesn't make sense to add that for one case.

Does the following patch look OK ?

Thanks,

- KK

Signed-off-by: Krishna Kumar <krkumar2 at in.ibm.com>

diff -ruNp org/core/cma.c new/core/cma.c
--- org/core/cma.c	2006-09-13 10:56:56.000000000 +0530
+++ new/core/cma.c	2006-09-13 10:57:20.000000000 +0530
@@ -2332,12 +2332,9 @@ static int cma_remove_id_dev(struct rdma
 
 static void cma_process_remove(struct cma_device *cma_dev)
 {
-	struct list_head remove_list;
 	struct rdma_id_private *id_priv;
 	int ret;
 
-	INIT_LIST_HEAD(&remove_list);
-
 	mutex_lock(&lock);
 	while (!list_empty(&cma_dev->id_list)) {
 		id_priv = list_entry(cma_dev->id_list.next,
@@ -2348,8 +2345,7 @@ static void cma_process_remove(struct cm
 			continue;
 		}
 
-		list_del(&id_priv->list);
-		list_add_tail(&id_priv->list, &remove_list);
+		list_del_init(&id_priv->list);
 		atomic_inc(&id_priv->refcount);
 		mutex_unlock(&lock);