Re: 2.5.59-dcl2

[Luben Tuikov <luben@splentec.com>]

Mike Anderson wrote:
>>
>>The scsi mid-layer shouldn't free a command that hasn't actually been
>>aborted/reset because it *could* come back from the firmware after the
>>timeout has expired, and the driver has a reference to it (need
>>refcounting...)  This could potentially lead to an exhaustion of the command
>>pool though, if a command *never* comes back.
>>
> 
> 
> This is bad to return the command if the eh cannot cancel it from
> the LLDD. Then again the eh routines provided by the driver are not very
> useful. We could change the error handler to mark cmds that have and
> have not been canceled and then at the end do something with the
> un-canceled ones. The do something is unclear.

1. Right, if the eh_abort_handler() (read: eh_cancel_command())
could *not* complete cancellation of the command, SCSI Core
should *not* repossess it.

OTOH, after successfull eh_device_reset() (use your imagination: UYI),
or eh_host_reset() (again UYI), LLDD is in its full right to *repossess*
all pending LLDD status commands. (See bottom of text.)

2. There are two ways to implement object states.  One is to ``mark them''
via an object variable which represents the state and the other is to
use containers* /representing/ the different states.

* Queues, lists, etc.

The first method is quite, quite trivial and worth no discussion except
to mention that it just adds more cruft to the object itself.

The other is what would normally be implemented in any self respecting program,
and has many, many advantages, e.g. one can use a priority queues, on top of it
being a state queue, etc.

For this reason what you'd want to do is use a per device variable
	struct scsi_device::struct list_head lost_cmds;
where
	struct scsi_cmnd::struct list_head list;    /* scsi_cmnd participates in queue lists */
is hooked. (The comment is copied verbatim from my patches, now in scsi-combined-2.5.)

When a command couldn't be cancelled (eh_* returned failure), you *could* move
the command into that queue and make SCSI Core be aware of it, e.g. when freeing
the device.  I said ``could'' since this is a policy issue and will have to be
decided by more than one knowlegable scsi developer of linux-scsi.

As to LLDD: after ABORT TASK TMF, no further responses should be sent from
the target device to the initiator port regarding that task.  The initiator port
is the LLDD or SCSI Core *if* LLDD does its own queuing.  ((Strictly speaking
the Initiator Port is always the LLDD, but if it does its own queuing it will have
to notice the ABORT TASK TMF.)) What this means is that SCSI Core *can* make some
assumptions.

-- 
Luben