[ofa-general] Re: bug in cma_iw_handler? (was hotplug event handle question)

[Steve Wise]

On Thu, 2007-04-26 at 08:33 -0700, Sean Hefty wrote:
> >Off the top of my head, I don't think so.  Since the state is staying the same,
> >we now have the potential of another thread invoking a callback to the same id.
> >For example, the ib_cm could callback with a connect or reject event, which
> >gets
> >propagated to the user.  The user will now see two callbacks for the same id.
> >Depending on the execution of the threads, one could completely run, with the
> >user wanting to destroy the associated id.  The second callback would then be
> >invoked after the id was destroyed.
> >
> >The state combined with the dev_remove counter were used to serialize the
> >callbacks.  So we still need something to serialize the callbacks.
> 
> Steve,
> 
> Looking at the cma code, I see the following in cma_ib_handler:
> 
> 	atomic_inc(&id_priv->dev_remove);
> 	if (!cma_comp(id_priv, CMA_CONNECT))
> 		goto out;
> 
> The cma_iw_handler only has:
> 
> 	atomic_inc(&id_priv->dev_remove);
> 
> without the state check, the cma_iw_handler can start running after we've
> received a device removal event, which can result in multiple callbacks or a
> callback after destruction.
> 
> If you agree, I will add the state check to the cma_iw_handler.
> 

I think you're right.  We need the same logic in cma_iw_handler()...