[openib-general][PATCH][kdapl]: inc/dec module ref count

[James Lentini]

Hmm...this is a tricky one. The ib_mthca module can be rmmod-ed at any 
time. That would break things in kdapl. Consider this scenario:

  consumer opens IA
  rmmod ib_mthca (IB support is pulled out from under us)
  rmmod kdapl_ib (user is trying to fix things)

With this patch, the kdapl_ib module's use count would be 1. The user 
would only be able to rmmod kdapl_ib if the kernel was compiled with 
CONFIG_MODULE_FORCE_UNLOAD.

>From my perspective, the current behavior seems better given the 
situation with ib_mthca. This seems acceptable if the ability to rmmod 
is restricted to knowledgeable sysadmins. What do you think?

One more comment below:

On Thu, 28 Jul 2005, Guy German wrote:

> [kdapl]: increments the module ref count on ia_open, thus making
> sure the kdapl_ib module would not be rmmod-ed while in use
>
> Signed-off-by: Guy German <guyg at voltaire.com>
>
> Index: infiniband/ulp/kdapl/ib/dapl_ia.c
> ===================================================================
> --- infiniband/ulp/kdapl/ib/dapl_ia.c	(revision 2914)
> +++ infiniband/ulp/kdapl/ib/dapl_ia.c	(working copy)
> @@ -649,6 +649,7 @@ int dapl_ia_open(const char *name, int a
> 	status = 0;
> 	*ia_ptr = (struct dat_ia *)ia;
> 	*async_evd = (struct dat_evd *)evd;
> +	try_module_get(THIS_MODULE);

We've been using the following convention to indicate that we don't 
care about the return value:

  (void) try_module_get(THIS_MODULE);

>
> bail:
> 	if (status != 0)
> @@ -679,6 +680,7 @@ int dapl_ia_close(struct dat_ia *ia_ptr,
> 	else
> 		status = -EINVAL;
>
> +	module_put(THIS_MODULE);
> 	return status;
> }
>