Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58

Mike Anderson
2003-01-17T20:25:23Z

Oliver and Alan I am trying to catch up on this thread so I did not
reply directly to your concerns, but I think they are covered below.

Matthew Dharm [mdharm-scsi@one-eyed-alien.net] wrote:
> On Fri, Jan 17, 2003 at 11:55:36AM +0100, Oliver Neukum wrote:
> > That is simply wrong. Reporting somebody having pulled a plug must
> > not fail. What are you supposed to do with an error here?
> >
> > There must be a way for a LLD to report that reliably.
> > If the answer is, take that lock, call that function, error all pending
> > requests, release that lock and call that function, it's OK.
> >
> > But it must work in all cases.
>
> I absolutely agree. The device is gone. I can't do anything about it.
> If the SCSI layer decides it can't let go, what am I supposed to do about
> it?
>
> In a separate discussion with Mike, he mentioned that you can't
> scsi_remove_device() unless there are no pending commands.
>
> How the hell is an LLD supposed to assure that!?!?
>

I believe that the scsi_remove_host function the way it is currently is
not the correct function. The SCSI needs to separate the device gone
from freeing. There maybe some unbounded cleanup as the request_queue
that is exported to the block layer is part of the scsi_device which is
a child of the virtual usb SCSI adapter. The only way to reduce the
unbounded time is possibly we reorganizing some sysfs tree object
layouts.

> The minute I error a command and call scsi_done(), I can get a new one.
> Unless I lock out requests with scsi_block_requests(), but that comes with
> major warnings about needing to get unblocked.
>

Well in the case of the device really being gone does the LLD need to be
worried about being unblocked. I get the feeling from this thread that
this is probably the wrong interface.

> The way this should work is that the LLD calls scsi_remove_device(), and
> that cuts off the flow of commands. The LLD can promise to error-out any
> pending commands in the device command queue.
>
> That is, unless scsi_block_requests() and scsi_unblock_requests() are more
> useful than the documentation suggests... block(), error all commands,
> unregister()... that would make some sense. We could call
> scsi_block_request() as soon as we know the unit is gone, and unregister()
> as soon as the queue is empty.

We should really ensure that we have good separation between stopping device
IO, device gone, and release resources.

- SCSI seems to have the flags to stop the IO, but instead of
scsi_block_requests we may want to export the setting of
device online. This can be done from sysfs now, but
not from the driver ( the driver does have a handle to the
device, but it would be better to have an interface in case we
need to do something addition operations).

- Possibly add a scsi_remove_device that would always succeed and
a version of scsi_remove_host that calls scsi_remove_device for
all devices. Though with the recent change to SCSI remove host to
allow non sysfs device registration I do not believe we could
ensure devices would be cleaned up.

- SCSI would need to support ref counting so that resources are
not removed to soon.

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