Hi, James Lentini <mailto:[EMAIL PROTECTED]> wrote: > On Sun, 31 Jul 2005, Muli Ben-Yehuda wrote: > >> On Sun, Jul 31, 2005 at 06:08:11PM +0300, Guy German wrote: >>> Hi Muli, >>> >>> Wouldn't it be solved by moving the try_module_get call to the >>> beginning of the dapl_ia_open function ? >> >> No. Even if it's theoretically the first line in the function, the >> compiler can and will create a function prologue that will run before >> you raise the reference count (same thing with decrementing the ref >> count at module unload time and the function epilogue). You must do >> module reference counting before executing even one instruction from >> the module. >> >>> You are right - try_module_get() can fail when the module is not >>> ready to be entered. should be something like: >>> + if (!try_module_get(THIS_MODULE)) >>> + return -EBUSY; >> >> Yes - but at the caller, not callee. > > Putting this in the caller (i.e. dat_ia_open and dat_ia_close) does > sound like a better option.
Sounds good to me too. > > Guy, can you investigate why the ib_mthca module doesn't have a > reference count and see if it relates to hotplug? I think > kdapl_ib and > ib_mthca should have the same policy regarding this issue. As I understand, consumers are working over ib_core and not over ib_mthca directly. So, if (from a hotplug reason) ib_mthca goes down, ib_core consumers can get notified of the event, by an upcall. If you take this model to dapl, I think it would influence the way dapl consumers need to do things (like registering an upcall and know what to do in case kdapl_ib is down). I also don't know how many consumers really need "dapl hotplug"... Guy _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
