[lkml]   [2009]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 25/20] sysfs: Only support removing emtpy sysfs directories.
On Thu, 2009-05-28 at 16:02 -0400, Alan Stern wrote:
> On Thu, 28 May 2009, James Bottomley wrote:
> > > > However, the piece that's missing, is the fact that all of
> > > > this has to be tied into the host state. If the host is running, you
> > > > can't remove the target from visibility even if all its children are
> > > > invisible because it might get another visible child added.
> > >
> > > Are you sure about that? It's not obvious at all to me.
> >
> > Yes ... otherwise you have to elongate the DEL interval from a few ms to
> > potentially anything. That would allow locking a target in a dying
> > state and prevent any new LUNs being added.
> How so? Why not unlink the target from the host's list when the
> device_del() call returns? A new target can be created any time after
> that, since the old one is now completely invisible.

The answer to that one is several emails back: we need the target in the
host list for the lifetime of the devices ... it's alterable, but even
more auditing.

> > > For example, suppose during scanning it turns out there are no LUNs at
> > > a particular target address. Why should the empty target be retained?
> > > You'd end up with unusable targets at all possible bus addresses.
> > >
> > > Besides, if a target is removed from visibility and then another child
> > > is added, the answer is simply to create a new target structure.
> > > There's already code in scsi_alloc_target() to do this.
> >
> > As I've said several times, this could be done, but we'd have to audit
> > the code paths to make sure we allow for multiple same targets in the
> > list.
> No, not if the old target is removed from the host's list before the
> new target is added.
> Is there any reason the old target has to remain on the list? If
> there is, we can introduce a new state: STARGET_CLEANUP. The old
> target gets put into this state when device_del() returns. List
> entries in that state are ignored by __scsi_find_target() or whatever
> else looks through the list.
> Alan Stern
> P.S.: Does scsi_target_reap() really ever get called in non-process
> context? I couldn't find any place where that might happen.

>From the device release, which is done by last put, which could be I/O


 \ /
  Last update: 2009-05-28 22:13    [W:0.157 / U:1.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site