I'm trying to fix up the usb device reference counting
logic right now and running into issues where host controllers try to
access urbs after their devices have been removed from the system :(
Not supposed to happen ... when they call giveback(), that's supposed to
mean they've forgotten about that URB. Is it buggy disconnect() logic,
or some HCD calling giveback too early?
I'm seeing uhci_irq() get called for an urb that belongs to a usb device
that has already been disconnected. Things go wrong when
I was going to guess it was UHCI related, because I saw it
doing that ages ago and I don't think the issue was fixed.
The issue I recall (maybe incorrectly) was a QH memory management
issue, where the QH couldn't be freed right away (because of the
way the UHCI schedule is used) so it got put on a list to be freed
later, after delaying until the next frame triggered an IRQ.
But instead of cleaning out things like qh->dev and/or qh->urbp
right away, those pointers got left around ... the trouble happened
when they got used in that IRQ. The giveback() meant that it would
not be using those pointers again.
uhci_transfer_result() is called, which calls usb_release_bandwidth()
which expects dev->bus to be a valid pointer. I thought that after
deallocate() is called on the bus for the device, everything would be
cleaned up.
Yes, but UHCI doesn't provide that method. Which would be OK
if it weren't using those now-invalid pointers in the IRQ that
cleaned up that QH.
Here's the patch to the usb core that shows this quite nicely:
Looks very similar to one I worked with for a while, which
is how I noticed the problem I tried to describe above. Yes,
this SHOULD work because of the API contract for each of the
routines.
And in fact it's more correct than the current code, since all
users of bus->op->deallocate() have always expected to get
called in a context that can sleep/schedule ... and if drivers
disconnect() wrong, the current approach might do it in_irq().
This is last significant structural issue that I know of with
disconnect() processing ... those usb-serial races you mentioned
are not the only place such problems have appeared. Maybe a
few other tweaks will be needed to make this patch work, but
not too many ... it's the Right Thing to do.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
