I had to look at usb-uhci and locking in it once again;
this time I know what is wrong with David-B's "fix"
<http://marc.theaimsgroup.com/?l=linux-usb-devel&m=98580988401128&w=2>
Look at the original code and you will see that it was a
sure way to deadlock. Our order is list --> urb, but here
we take list while holding urb. The order list --> urb
is dictated how uhci_interrupt takes list first.
David did not fix _that_ aspect of the problem.
Now, what about calling a completition function with a lock held.
I am sure that not a single driver unlocks URBs
before freeing them. I explained before that if a CPU
spins on that lock, slap poisoning will oops it.
If problems crop up so thick, surely something is very wrong,
so I started to make lists and charts, and found something curious.
It seems to me that all places where urb is locked by itself are
under the list lock too. The exception is when list lock is
illegally dropped and reaquired in process_urb, which we have
to remove anyways due to ordering. Nowhere else we use the
urb lock by itself.
I suggest we get rid of any instances of urb->lock in usb-uhci.
It does not serve any useful purpose, and is a terrible bug
generator.
-- Pete
P.S. I looked briefly how Johannes does it, because I know that
he uses per-urb lock. He does a more fine grained locking,
e.g. everything is under urb lock, but sometimes picks list
lock (N.B.: opposite lock order). Since his driver is the
future, I do not think it makes any sense to retrofit his
scheme into usb-uhci.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
