All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Kernel development list <linux-kernel@vger.kernel.org>,
	Patrick Mochel <mochel@digitalimplant.org>
Subject: Re: Inconsistency in sysfs behavior?
Date: Wed, 7 Jan 2004 09:27:50 -0800	[thread overview]
Message-ID: <20040107172750.GC31177@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0401071039150.850-100000@ida.rowland.org>

Note, Pat's email address has changed, I've changed in the CC:

On Wed, Jan 07, 2004 at 10:48:44AM -0500, Alan Stern wrote:
> The following appears to be an inconsistency in the way sysfs behaves.  
> Tell me what you think...
> 
> When a user process parks its CWD in a kobject's sysfs directory and then
> the kobject is unregistered, of course the directory is forced to remain
> in existence (albeit unlinked) because of the reference held by the
> process.  But it does not in turn hold a reference to the kobject; the
> kobject will be deleted immediately if nothing else refers to it.
> 
> On the other hand, if a user process opens a sysfs attribute file and then
> sysfs_remove_file() is called, again the file is forced to remain in
> existence (albeit unlinked) because of the reference held by the process.  
> But now it _does_ hold a reference to the kobject; if the kobject is
> unregistered it will not be deleted until the user process closes the
> attribute file.
> 
> Why this non-parallel behavior?

Because it is very difficult to determine when a user goes into a
directory because we are using the ramfs/libfs code.  It also does not
cause any errors if the kobject is removed, as the vfs cleans up
properly.

Only when a file is opened does a kobject need to be pinned, due to
possible errors that could happen.

Hope this helps,

greg k-h

  reply	other threads:[~2004-01-07 17:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-07 15:48 Inconsistency in sysfs behavior? Alan Stern
2004-01-07 17:27 ` Greg KH [this message]
2004-01-07 21:50   ` Alan Stern
2004-01-07 21:56     ` Greg KH
2004-01-07 22:24       ` Alan Stern
2004-01-07 22:34         ` Greg KH
2004-01-08 10:32   ` Maneesh Soni
2004-01-08 20:19     ` Greg KH
2004-01-09  4:56       ` Maneesh Soni

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=20040107172750.GC31177@kroah.com \
    --to=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@digitalimplant.org \
    --cc=stern@rowland.harvard.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.