Re: Unregistering interfaces
From: Maneesh Soni
Date: Tue Mar 30 2004 - 00:51:16 EST
On Mon, Mar 29, 2004 at 03:31:17PM -0800, Andrew Morton wrote:
> Greg KH <greg@xxxxxxxxx> wrote:
> > > The module should remain in memory, "unhashed", until the final kobject
> > > reference falls to zero. Destruction of that kobject causes the refcount
> > > on the module to fall to zero which causes the entire module to be
> > > released.
> > >
> > > (hmm, the existence of a kobject doesn't appear to contribute to its
> > > module's refcount. Why not?)
> > It does, if a file for that kobject is opened. In this case, there was
> > no file opened, so the module refcount isn't incremented.
> hm, surprised. Shouldn't the existence of a kobject contribute to its
> module's refcount?
> > > Maybe a shrink_dcache_parent(dentry) on entry to simple_rmdir() would
> > > suffice?
> > Will that get rid of the references properly nwhen we remove the
> > kobject?
> That's one the dcache guys could address better, but I was mainly proposing
> it as a way of removing any negative dentries. But it appears that we have
> problems beyond negative dentries?
shrink_dcache_parent() will only free up the zero ref. counted dentries,
positive or negatvie doesnot matter. But we may have some faulty user space
app holding a sysfs file, sysfs directory, corresponding kobject, module etc.
(Greg, I am including the reply for other thread also here)
Fix for these problems will depend upon the life time rule for
modules Vs kobjects Vs dentries. When and what should die or live?
I am not very clear about how the first two behave. Still I can think
of a solution within sysfs like this as Alen suggested. But again I am not
very sure if this can be done properly without any races. But anyway I am
1) backout my patch sysfs-pin-kobject.patch
2) handle NULL d_fsdata while trying to access the corresponding kobject
for an attribute file.
Linux Technology Center,
IBM Software Lab, Bangalore, India
Phone: 91-80-25044999 Fax: 91-80-25268553
T/L : 9243696
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/