Re: panic after removing usb flash drive

Bernd Walter wrote:
> On Wed, Aug 31, 2005 at 09:38:20AM -0600, Scott Long wrote:
> 
>>Ben Kaduk wrote:
>>
>>>On 8/31/05, Kyle Brooks <captinsmock_at_columbus.rr.com> wrote:
>>
>>1)  When the thumbdrive gets pulled, the umass driver gets told to
>>detach.  It tries to detach itself from CAM, but things don't get torn
>>down correctly because there is an open reference to the target in CAM
>>(because there is a mounted filesystem on the device).  umass truddles
>>along anyways and goes away, leaving lots of dangling pointers in CAM
>>that blow up on the next attempted I/O access.
>>
>>Part of the problem here is that the umass driver is architected wrong.
>>It creates a SIM, bus, and target instance for every umass device that
>>gets inserted.  When the device gets pulled, it tries to tear down
>>each of those instances all at once.  CAM simply wasn't designed for
>>this.  It was designed for the SIMs and buses to be long-lived objects
>>where only the targets (and luns) come and go.  Making umass fit this
>>model would invlove turning it into two logical drivers.  One would be
>>a SIM that would attach to the root hub instance of each USB controller
>>and would treat the USB bus as a CAM bus.  The other would be a target
>>driver that gets created and destroyed on a per-device basis as those
>>devices come and go.  When a umass device gets plugged in, the USB
>>framework would tell the apprpriate SIM to create a target instance.
>>When the device gets pulled, the framework would tell the SIM to detach
>>and destroy the target.  No dangling pointers would be left behind by
>>the SIM going away.  I have some prototype work in progress on this.
> 
> 
> This would really a step backward.
> Originally we had LUN creation/deletion on shared SIM and lots of
> different problems.
> SIM deletion should really be fixed - not only for umass, but generally
> as we live in a world with removeable cards.

Bugs in the umass detach code are immediately responsible for the
problem, but you are correct that CAM in general doesn't like SIMs
going away.  DFly worked on this a while back, but I don't recall
whether the work there was to add more sanity checks in the data
path (which I don't want to do), or if it was the correct approach of
flushing and quiescing the data/queuing, topology, and error recovery
paths.

> Technically a shared sim with using targets could be made work for
> umass as it's defined today, but it won't work for USB to SCSI
> converters - that we don't support one of these adapters today doesn't
> solve the problem.

This is a completely different situation.  A USB-SCSI adapter would
provide its own SCSI bus that is separate from the USB bus with its
own queueing resources and own error recovery mechanisms.

> Is is a academical standpoint defining where in the USB/umass
> infrastrukture the SIM is located, but I personally always saw it
> inside the USB-device and not on the USB.
> USB is just a transport medium and not a SIM in the same way as PCI is
> just a transport medium for a classical SCSI-Interface.
> Yes - umass creates a SIM, bus and targed, because that is what a user
> really attaches/detaches.
> 

It is muddy, but for a mass storage class device, you are using the
USB bus as the transport medium and you are using the USB controller
as the transport initiator.  Command queueing and resource arbitration
happens in the USB controller and driver, not in the umass device or
driver.  Same for error recovery.  The USB controller is essentially
acting as a SCSI controller, just with a USB bus instead of a SPI bus.
The whole point of CAM is to assist with queueing and arbitrating bus
resources.  There is no way that the SIM-per-device approach can provide
this information.

Your analogy of a PCI bus is correct for the USB-SCSI adapters, where 
the adapter is doing a full conversion and bridge from one bus type to
another.  It's not true for a umass device where it's merely using the
USB bus as a SCSI transport.

> 
>>In any case, the panic posted in the grandparent message implicates CAM 
>>and umass, which is what I would expect.  There may be more layers of
>>problems underneath it.
> 
> 
> Possible, but lets solve them.
> 

Indeed.

Scott