Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1

[David Brownell <david-b@pacbell.net>]

>>>>...  hold
>>>>a reference to the usb_device maybe long after the device has
>>>>been disconnected.  This is supposed to be OK, but from your
>>>
>>>... no, that's not supposed to be OK.  Returning from disconnect()
>>>means that a device driver is no longer referencing the interface
>>>the driver bound to, or ep0.
>>
>>Well, I thought Greg wanted it to be OK :)  Anyway, I don't use
>>the device after disconnect except to take the semaphore
>>(dev->serialize), check for disconnection (dev->state), and
>>of course to execute a usb_put_dev.  Surely this usage should
>>be OK?

Why do you even need that much though?  You're not allowed to
be USING the device any more; that's the sense in which I
was using "reference".   Refcounting is orthogonal, except
in the sense that to use without owning/borrowing a refcount
will likely cause oopsing someday.


> As long as your disconnect routine doesn't do usb_put_dev, so that it

There's an implicit usb_get_dev() associated with probe(),
and an implicit usb_put_dev() associated with disconnect().
If you're going to add an explicit put(), you need to also
add an explicit get().  Few drivers do; most rely on the
implicit refcounts.

But if you keep an extra reference to the device, you'd
need some way to get rid of it.

Yes, "usbfs" is wierd in lots of ways ... it's got references
associated with several distinct roles, including implicitly
associated with device creation, and so I'd suspect it doesn't
keep them all straight.

Plus, using the claim/release binding model (in its current
state) opens it up to a different family of bugs ... since
that doesn't hook up properly to the driver model yet, and
making it do so is non-trivial.


> maintains its reference, I don't see a problem.  But why do you want to
> check dev->state later on?  Once your disconnect routine has returned, you
> should be totally through with the device.  You should no longer care
> whether it's attached or not.
> 
> And of course, remember that there are valid reasons for your disconnect 
> routine to be called even when the device remains attached.  (rmmod is a 
> good example.)

And adding special case logic for rmmod paths isn't a good thing;
better just to implement disconnect() as I described.

- Dave