Re: [PATCH] scsi_set_host_offline (resend)

[Luben Tuikov <tluben@rogers.com>]

Oliver Neukum wrote:
>>*But*, the _important__point_ is that the LLDD must be able to handle
>>requests (queuecommand()) to non-existant (== just removed) devices,
>>and not oops, or whatever.
> 
> 
> For how long? That's the question.

As soon as scsi_dev_removal()/scsi_set_dev_offline() returns
you may assume you can free all _your_ resources.  I.e.
the upper subsystem should handle it from that point on.
 
>>So, in effect, you just call usb_dev_removal(dev) (to be written),
>>and free _your_ resources on the device. (note important point above)
> 
> 
> The way it is in USB is a little different as the USB device drivers do
> not go directly to the hardware. It would be:
> 
> HCD -> USB core -> LLDD -> generic SCSI -> ...
> Steps 1 to 3 work, 4 doesn't.

Not yet, soon maybe.

> If they can't block, they cannot clean up commands still in flight.
> Eventually something needs to wait for the outstanding commands.

I don't see it.

(Upper level: )
Pending commands could be invalidated at once, via their callback
to the upper subsystem; and any new incoming commands to device x
could be invalidated at the moment they come in.

(Lower level: )
Note that during the call to scsi_dev_removal() your driver
may get its host_reset/device_reset function called to abort all
pending commands (so as to leave the device in a predictable state).
At which point, depending on the transport, _your__driver_ may need
to sleep until the task management function response comes back (say over
a network).

All in all, it's not that bad.
-- 
Luben