From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roland Dreier Subject: Re: [PATCHv8 04/11] ib_core: IBoE CMA device binding Date: Fri, 14 May 2010 15:08:14 -0700 Message-ID: References: <20100218172403.GE12286@mtls03> <20100513082613.GC16073@mtldesk030.lab.mtl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: <20100513082613.GC16073-8YAHvHwT2UEvbXDkjdHOrw/a8Rv0c6iv@public.gmane.org> (Eli Cohen's message of "Thu, 13 May 2010 11:26:13 +0300") Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Eli Cohen Cc: Eli Cohen , Linux RDMA list , ewg List-Id: linux-rdma@vger.kernel.org > > 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. I see... we can't call the consumer's callback directly since it might have locking assumptions. It would be nice if we didn't have this reference counting sometimes used and sometimes not used. I'll have to think about whether this can be made cleaner. - R. -- Roland Dreier || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- 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