From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Hannes Reinecke <hare@suse.de>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Kay Sievers <kay.sievers@vrfy.org>,
SCSI development list <linux-scsi@vger.kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
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 16:01:34 +0000 [thread overview]
Message-ID: <1243440094.6067.10.camel@localhost.localdomain> (raw)
In-Reply-To: <4A1D2583.8040803@suse.de>
On Wed, 2009-05-27 at 13:35 +0200, Hannes Reinecke wrote:
> Hi all,
>
> Alan Stern wrote:
> > On Wed, 27 May 2009, Kay Sievers wrote:
> >
> >> On Wed, May 27, 2009 at 01:49, James Bottomley
> >> <James.Bottomley@hansenpartnership.com> wrote:
> >>
> >>> OK ... perhaps we have to wait a little harder: try this; it waits until
> >>> all the targets have disappeared from visibility via an event.
> >> That seems to work fine here.
> >
> > It's good for a short-term fix. For the longer term, I still think
> > it's a mistake to wait for the sdevs to be released before deleting the
> > target. It gives user programs the ability to block the host-removal
> > thread indefinitely.
> >
> Quite so. We should rather see to have the reference counting fixed
> properly, than this would go away automatically.
Hardly ... our current refcounting is on destruction (releases). This
problem is an instance of visibility (the del calls) we need the
visibility teardown to work nicely. We currently have no refcounting on
the visibility. Even if we did (and we could add a ref on when the
underlying device del calls are done), what happens if the target needs
to become visible again. Apparently the generic device infrastructure
can't accept doing an add on a previously del'd device.
The most obvious way of fixing this is to have a special case for
targets of dying hosts ... they could call del early on the
understanding that they're never getting new underlying devices. That
would allow the wait to trigger on the last target del, which is what is
optimal.
James
next prev parent reply other threads:[~2009-05-27 16:01 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 [this message]
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
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=1243440094.6067.10.camel@localhost.localdomain \
--to=james.bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=cornelia.huck@de.ibm.com \
--cc=ebiederm@aristanetworks.com \
--cc=ebiederm@xmission.com \
--cc=gregkh@suse.de \
--cc=hare@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