On Mon, 2010-10-04 at 18:05 -0700, Joe Eykholt wrote: > > On 10/4/10 5:36 PM, Robert Love wrote: > > vports are grabbing module references but not releasing > > them. > > > > Do a module_put() in fcoe_interface_release() so that > > vports release module references. Also, move the > > try_module_get() into fcoe_interface_create() to > > create symetry in the calls. > > > > This patch is only for discussion purposes and has not > > been fully tested. There may be another issue with > > reference counting without NPIV. I was seeing refereces > > grabbed by scsi_device_get() that were not being > > released after destroying the fcoe interface. However, > > my kernel tree is fairly old so more testing is needed > > before drawing any conclusions. > > --- > > drivers/scsi/fcoe/fcoe.c | 44 > > ++++++++++++++++++++++---------------------- > > 1 files changed, 22 insertions(+), 22 deletions(-) > > > > diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c > > index d23a538..a1d4bdc 100644 > > --- a/drivers/scsi/fcoe/fcoe.c > > +++ b/drivers/scsi/fcoe/fcoe.c > > @@ -356,10 +356,25 @@ static struct fcoe_interface > > *fcoe_interface_create(struct net_device *netdev, > > struct fcoe_interface *fcoe; > > int err; > > > > +#ifdef CONFIG_FCOE_MODULE > > Is the ifdef-ed code needed? It looks to me like try_module_get takes > care of things even if built-in, although it checks for !GOING instead > of LIVE. So, I'm just asking ... not sure. I see you're just moving > code we already had. Note that this returned a different errno before, > but it doesn't matter.
Yeah, I guess after this patch, if the module was not live we would return an -ENOMEM message instead of an -ENODEV. An -EBUSY or something else might be more appropriate. I have a patch that has fcoe_interface_create() return error codes encoded in the returned fcoe_interface pointer. I think it's correct, but it seems like heavy lifting. The module states are: LIVE, COMING and GOING. The comment says, "Module paramter sysfs files are writable before the module_init function is called and after module_exit." So it sounds like we could get the fcoe_create call from sysfs before the module has been initialized. I assume that the module would be in the COMING state for that to happen. I just noticed the strong_try_module_get() routine. It checks for COMING before doing the try_module_get, but it's not exposed to other modules. I can't reproduce the non-NPIV reference count problem I was seeing before, so I'm going to finish off this patch. I'll post an updated patch soon. Thanks, //Rob _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
