Re: [PATCH 25/20] sysfs: Only support removing emtpy sysfs directories.

[James Bottomley]

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
context.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/