Re: Questions about scsi_target_reap and starget/sdev lifecyle

Alan Stern
2005-06-22T16:16:36Z

On Wed, 22 Jun 2005, Luben Tuikov wrote:

> The notify event can "travel" right behind flush-cache and "close doors"
> behind. (since it travels from the application client to the device)

Are you sure about that? One way to generate such a notify event is to
rmmod the LLDD. The event is then generated by the LLDD and it travels up
to the midlayer, by way of scsi_remove_host. You seem to be saying that
there should be a separate API for the LLDD to notify the midlayer that it
is about to be unloaded.

> Yes indeed: the proper order is:
> * lock the front door,
> * empty all rooms,
> * call scsi_remove_host().
>
> This is on _hot-unplug_ since the event came from the SDS.
> In the event of a notified unplug, the event would be known to
> SCSI Core _before_ it is known to the LLDD, so SCSI Core would
> lock the "fence gate", send flush-cache (which would seem as any
> other command to you), then wait for that to return (which would
> mean no other commands are pending, since this was the last command
> to be sent after locking the "fence gate") and then it would
> call scsi_remove_host() or whatever appropriate.

Currently there is nothing like your "fence gate", although there should
be.

> > usb-storage. I don't know how any other hot-unpluggable LLDDs will handle
> > cancellation during unplug.
>
> In case the LLDD is implemented properly, just doing nothing should suffice. ;-)

So should the midlayer no longer try to cancel outstanding commands when a
host is removed? Can it rely on the LLDDs to do so?

Alan Stern