Re: [PATCHv8 04/11] ib_core: IBoE CMA device binding

[Eli Cohen <eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html