Re: Questions about scsi_target_reap and starget/sdev lifecyle

[Mike Anderson <andmike@us.ibm.com>]

Alan Stern [stern@rowland.harvard.edu] wrote:
> On Tue, 21 Jun 2005, Christoph Hellwig wrote:
> 
> > On Tue, Jun 21, 2005 at 04:04:06PM -0400, Alan Stern wrote:
> > > This objection runs up against an issue we discussed some time ago.  
> > > Should the intended meaning of scsi_remove_host be simply that the kernel
> > > needs to stop using the HBA reasonably soon?  In that case you are right.  
> > > Or should the intended meaning be that the HBA is actually gone
> > > (hot-unplugged) and all further attempts to use it will fail?  In that
> > > case it doesn't matter.  The best ways to resolve this issue may be to
> > > have a separate scsi_host_gone routine or to add an extra argument to
> > > scsi_remove_host.
> > 
> > It must mean both because we don't know whether a hot unplug happened or
> > not.  The ->remove callbacks don't tell us.
> 
> I would describe it differently: Since you don't know whether a hot-unplug 
> occurred, you might as well assume it did not.  There's no harm in this, 
> because if the HBA really was unplugged then it doesn't matter what you 
> do; everything will fail.
> 

I have asked this multiple times, but I will again. If the hba knows to
fail everything by some internal state in the LLDD why does it not also
know to flush all commands back to the scsi mid layer in this unplugged
state so we do not have to deal with canceling them from the mid-layer. 

I think it has been stated many times if commands always go in through
queuecommand and always return through scsi_done it makes the chances of
errors a lot less.

> But those sd flush-cache commands are a problem.  Presumably you want to 
> send them _after_ all the outstanding commands have finished or been 
> cancelled.  What's the right way to allow those commands while rejecting 
> all others?

We have some notion of this already if you look in scsi_prep_fn (i.e.,
specials_only), but this is based on sdev state not shost. Checking for a
specials_only flag in scsi_dispatch may not be to clean. This may be why
we should look at a shost state model update and align sdev and shost to
clearly state what will happen to command.s

-andmike
--
Michael Anderson
andmike@us.ibm.com