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()... _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
