[openib-general] RFC: CMA backlog (was Re: CMA backlog)

[Sean Hefty]

Michael S. Tsirkin wrote:
> Here's an untested patch that does this. Comments?

Rather than exporting wrapper functions around atomic inc/dec, I would rather 
the user just maintain the current backlog themselves, with the patch limited to 
the cm.c file only.

> Index: src/drivers/infiniband/core/cm.c
> ===================================================================
> --- src.orig/drivers/infiniband/core/cm.c	2006-06-07 11:33:04.109937000 +0300
> +++ src/drivers/infiniband/core/cm.c	2006-06-15 15:50:34.222140000 +0300
> @@ -701,6 +701,19 @@ static void cm_reset_to_idle(struct cm_i
>  	}
>  }
>  
> +static void ib_destroy_cm_id_no_resp(struct ib_cm_id *cm_id)
> +{
> +	struct cm_id_private *cm_id_priv;
> +
> +	cm_id_priv = container_of(cm_id, struct cm_id_private, id);
> +
> +	cm_free_id(cm_id->local_id);
> +	cm_deref_id(cm_id_priv);
> +	kfree(cm_id_priv->compare_data);
> +	kfree(cm_id_priv->private_data);
> +	kfree(cm_id_priv);
> +}

I think that we need to dequeue and free any additional work items as well here. 
  See the bottom of ib_destroy_cm_id().  (It may makes sense for 
ib_destroy_cm_id() to call the new routine, but I'm not sure about that yet.) 
We will also need to wait for all references on the cm_id to go to 0.  (Incoming 
MADs could be accessing the cm_id, such as receiving a REJ while we're 
processing a REQ.)

There are likely some additional race conditions / cleanup not handled here as 
well.  We may still need to perform some state checking to ensure that the cm_id 
is not in any lists / trees, and that there are no outstanding MADs associated 
with the id.  (A user could have sent an MRA or other CM MAD from their 
callback, before returning an error.)

- Sean