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

[Sean Hefty]

>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.

- Sean