All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maneesh Soni <maneesh@in.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Greg KH <greg@kroah.com>,
	stern@rowland.harvard.edu, david-b@pacbell.net,
	viro@math.psu.edu, linux-usb-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: Unregistering interfaces
Date: Tue, 30 Mar 2004 11:21:35 +0530	[thread overview]
Message-ID: <20040330055135.GA8448@in.ibm.com> (raw)
In-Reply-To: <20040329153117.558c3263.akpm@osdl.org>

On Mon, Mar 29, 2004 at 03:31:17PM -0800, Andrew Morton wrote:
> Greg KH <greg@kroah.com> 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.
Refer http://bugme.osdl.org/show_bug.cgi?id=1884

(Greg, I am including the reply for other thread also here)
http://marc.theaimsgroup.com/?l=linux-kernel&m=108059485726012&w=2

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 
trying.
                                                                                
1) backout my patch sysfs-pin-kobject.patch
2) handle NULL d_fsdata while trying to access the corresponding kobject
   for an attribute file.

Maneesh
-- 
Maneesh Soni
Linux Technology Center, 
IBM Software Lab, Bangalore, India
email: maneesh@in.ibm.com
Phone: 91-80-25044999 Fax: 91-80-25268553
T/L : 9243696

  parent reply	other threads:[~2004-03-30  5:47 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20040328063711.GA6387@kroah.com>
     [not found] ` <Pine.LNX.4.44L0.0403281057100.17150-100000@netrider.rowland.org>
     [not found]   ` <20040328123857.55f04527.akpm@osdl.org>
     [not found]     ` <20040329210219.GA16735@kroah.com>
     [not found]       ` <20040329132551.23e12144.akpm@osdl.org>
2004-03-29 23:16         ` Unregistering interfaces Greg KH
2004-03-29 23:31           ` Andrew Morton
2004-03-30  0:01             ` Greg KH
2004-03-30  7:38               ` Maneesh Soni
2004-03-30 15:38               ` Alan Stern
2004-03-30  5:51             ` Maneesh Soni [this message]
2004-03-30 23:01               ` Greg KH
2004-03-30 23:16                 ` Andrew Morton
2004-03-30 23:30                   ` Greg KH
2004-03-30 23:57                     ` Greg KH
2004-03-30 23:56                   ` Alan Stern
2004-03-31  0:08                     ` David Brownell
2004-03-31  0:34                       ` Greg KH
2004-03-31 15:32                       ` Alan Stern
2004-03-31  0:33                     ` Greg KH
2004-03-31 15:54                       ` Alan Stern
2004-04-01  7:24                         ` Greg KH
2004-03-30 23:55                 ` [PATCH] back out sysfs reference count change Greg KH
2004-03-31  2:11                   ` [linux-usb-devel] " Benjamin Herrenschmidt
2004-03-31  2:19                     ` Andrew Morton
2004-03-31  9:26                       ` Maneesh Soni
2004-03-31 15:11                         ` Alan Stern
2004-04-01  5:17                           ` Maneesh Soni
2004-04-01  7:15                             ` Greg KH
2004-04-01 14:56                             ` Alan Stern
2004-04-02  4:38                               ` Maneesh Soni
2004-04-02 21:41                                 ` Alan Stern
2004-04-06 10:13                                   ` Maneesh Soni
2004-04-06 17:03                                     ` Alan Stern
2004-04-14 13:20                                     ` Maneesh Soni
2004-04-15 21:36                                       ` Greg KH
2004-04-15 22:10                                         ` Andrew Morton
2004-04-16  8:42                                           ` Maneesh Soni
2004-03-31 22:18                     ` Greg KH
2004-04-01  1:56                       ` Benjamin Herrenschmidt
2004-04-01  3:48                         ` Alan Stern
2004-04-01  6:55                         ` Greg KH
2004-04-01  7:13                           ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040330055135.GA8448@in.ibm.com \
    --to=maneesh@in.ibm.com \
    --cc=akpm@osdl.org \
    --cc=david-b@pacbell.net \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=stern@rowland.harvard.edu \
    --cc=viro@math.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.