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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
