public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Kay Sievers <kay.sievers@vrfy.org>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	SCSI development list <linux-scsi@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	Tejun Heo <tj@kernel.org>,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	linux-fsdevel@vger.kernel.org,
	"Eric W. Biederman" <ebiederm@aristanetworks.com>
Subject: Re: [PATCH 25/20] sysfs: Only support removing emtpy sysfs  directories.
Date: Wed, 27 May 2009 15:06:09 -0700	[thread overview]
Message-ID: <m1ljoi6w1a.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0905271736460.2669-100000@iolanthe.rowland.org> (Alan Stern's message of "Wed\, 27 May 2009 17\:38\:50 -0400 \(EDT\)")

Alan Stern <stern@rowland.harvard.edu> writes:

> On Wed, 27 May 2009, Eric W. Biederman wrote:
>
>> Alan Stern <stern@rowland.harvard.edu> writes:
>> 
>> >
>> > As fas as I know, they can't.  Instead, they can cause the SCSI layer 
>> > to unregister a sysfs directory containing a child directory.  :-)
>> >
>> > Basically, a user program can delay removal of the child (i.e., the
>> > target) directory indefinitely, because currently the target isn't
>> > unregistered when all its children are removed -- it's unregistered
>> > when all its children are _released_.
>> 
>> Ok.  Is this opens of /dev/sda1 and the like that are being held open by
>> userspace that are potentially causing problems?
>
> Yes, plus any other mechanism for preventing a struct device's refcount 
> from going to 0.

Thanks.  The discussion makes sense now.

>> I think I have the fix to that...
>
> The fix is to delete the target when its children are deleted, and not
> wait until the children are released.

I think I can do both.

I am currently working on a patchset which at the VFS layer disconnects a
fd from an underlying device.  It does the necessary use count tracking
and when the disconnect is done it returns.  As part of the disconnect it
calls the release method.

We already do this in at least sysfs, proc, sysctl, and sound.  So I
figure it is time to move this into some generic code so we don't need
to duplicate the bugs and the insanities.

Once merged it would take just a few lines of code to use this functionality.

Eric

  reply	other threads:[~2009-05-27 22:06 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <ac3eb2510905260927we3c748akbbcaf3f3ac1da096@mail.gmail.com>
2009-05-26 19:29 ` [PATCH 25/20] sysfs: Only support removing emtpy sysfs directories Alan Stern
2009-05-26 21:09   ` James Bottomley
2009-05-26 21:13     ` Kay Sievers
2009-05-26 21:56       ` Alan Stern
2009-05-26 22:03         ` Kay Sievers
2009-05-26 23:49           ` James Bottomley
2009-05-27  0:02             ` Kay Sievers
2009-05-27  2:17               ` Alan Stern
2009-05-27 11:35                 ` Hannes Reinecke
2009-05-27 16:01                   ` James Bottomley
2009-05-27 16:16                     ` Alan Stern
2009-05-27 16:24                       ` James Bottomley
2009-05-27 17:01                         ` Alan Stern
2009-05-27 17:08                           ` James Bottomley
2009-05-27 18:07                             ` Alan Stern
2009-05-27 19:44                               ` James Bottomley
2009-05-27 20:40                                 ` Alan Stern
2009-05-27 20:49                                   ` James Bottomley
2009-05-27 21:31                                     ` Alan Stern
2009-05-27 21:42                                       ` James Bottomley
2009-05-27 22:15                                         ` Alan Stern
2009-05-27 22:22                                           ` James Bottomley
2009-05-28 15:24                                             ` Alan Stern
2009-05-28 15:45                                               ` Eric W. Biederman
2009-05-28 17:51                                                 ` Alan Stern
2009-05-28 18:21                                               ` James Bottomley
2009-05-28 20:02                                                 ` Alan Stern
2009-05-28 20:10                                                   ` James Bottomley
2009-05-28 21:04                                                     ` Alan Stern
2009-05-29 12:32                                                       ` Hannes Reinecke
2009-05-29 20:08                                                     ` Alan Stern
2009-05-27 18:00                 ` Eric W. Biederman
2009-05-27 18:15                   ` Alan Stern
2009-05-27 18:24                     ` Eric W. Biederman
2009-05-27 21:38                       ` Alan Stern
2009-05-27 22:06                         ` Eric W. Biederman [this message]
2009-05-27 22:18                           ` Alan Stern
2009-05-26 21:39     ` Alan Stern
     [not found] <1243252896.4853.9.camel@poy>
2009-05-25 15:49 ` Alan Stern
2009-05-25 18:19   ` Kay Sievers
2009-05-25 20:14     ` Alan Stern

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=m1ljoi6w1a.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=cornelia.huck@de.ibm.com \
    --cc=ebiederm@aristanetworks.com \
    --cc=gregkh@suse.de \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tj@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox