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

James Bottomley
2009-05-28T20:10:39Z

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