On Wed, May 12, 2010 at 01:05:06PM -0700, Roland Dreier wrote: > > +static void iboe_mcast_work_handler(struct work_struct *work) > > +{ > > + struct iboe_mcast_work *mw = container_of(work, struct iboe_mcast_work, > work); > > + struct cma_multicast *mc = mw->mc; > > + struct ib_sa_multicast *m = mc->multicast.ib; > > + > > + mc->multicast.ib->context = mc; > > + cma_ib_mc_handler(0, m); > > + kref_put(&mc->mcref, release_mc); > > + kfree(mw); > > +} > > I'm having a hard time working out why the iboe case needs to schedule > to a work queue here since its already in process context, right? It > seems it would be really preferable to avoid all the extra pointer > munging and reference counting, and just call things directly. >
I assume that the caller might attempt to acquire the same lock when calling join and in the callback. Specifically, ucma_join_multicast() calls rdma_join_multicast() with file->mut acquired and ucma_event_handler() does the same. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html