On Thu, Feb 20, 2003, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > > > Actually, it seems to me that that unlinking after disconnect would
> > > > need to be a requirement for random disconnects to work.
> > >
> > > After physical disconnect, or logical disconnect?
> >
> > Physical. I consider logical disconnect when the last reference to the
> > device structure is put (ie it hits 0 and calls ops->deallocate())
> >
> > After that, the device structure doesn't exist anymore and it's not safe
> > to do anything (obviously).
>
> Absolutely right. And IMHO to a device driver that state is reached after
> it returns from disconnect().
I don't see why that is advantageous.
It sounds like it would just complicate the code even more.
> > > > I actually don't have a problem with submitting a request for a device
> > > > that's gone. It'll timeout. Big deal.
> > >
> > > Provided that the HCD doesn't keep state for devices.
> >
> > I don't see why that's a problem.
>
> The problem is the transition period.
> 1. disconnect()
> 2. driver does usb_submit_urb() nevertheless
> 3. deallocate -> HCD drops all device state
> 4. the URB from (2) completes -> BOOM
>
> If you reverse the order of (2) and (3) the HCD can return -ENODEV,
> but you can't guarantee that at least on SMP.
> To beat that we'd need an awful amount of refcounting and locking.
The refcounting already occurs atleast in 2.4:
if (atomic_dec_and_test(&dev->refcnt)) {
dev->bus->op->deallocate(dev);
usb_destroy_configuration(dev);
usb_bus_put(dev->bus);
kfree(dev);
}
At step 2 in your example, the reference count increments and step 3
never happens because the reference count > 0.
> > The borderline case with PCMCIA host controllers is that the HC
> > disappered, and as a result it should throw all of the existing pending
> > URBs into error?
>
> Right. I haven't checked that code path yet.
So, this is a situation where the HCD, or possibly the core, needs to track
all of the URBs.
> > > No it cannot, disconnect() has to wait for the unlink to complete.
> > Why is that?
>
> 1. Module unload
The module unload path is required to make sure all of the resources are
freed and not referenced, not necessarily disconnect() (although disconnect()
could ensure that happens with little or no code in the module unload path)
> 2. Freeing of internal state in the HCDs
I still don't see why this is the case.
> > Any new requests will result in an error anyway from the HC, so why
> > duplicate the functionality and complicate the rest of the code?
>
> It shouldn't need to. That functionality belongs into usbcore and needs
> a careful redesign of locking in usbcore, if it is to be done.
Huh? It's already implictily handled by the reference counting. No
thinking required.
> > > Besides, if HCDs keep per device states, they must have a time they
> > > can safely deallocate this information.
> >
> > Could you clarify what you mean by safely?
>
> Safely means that a kfree() is OK. HCDs should not be forced to keep
> reference counts on their internal states, nor should they have to need
> to deal with "shadow devices". That is a new device should not collide
> with already removed devices regardless of how a HCD organises internal
> state.
That shouldn't be the case. Actually, looking at the 2.4 code, something
changed. The disconnect() path frees the device id, when it should be
done in usb_free_dev after deallocate() is called.
I could have swore the code used to be correct a while ago.
JE
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
