On Sun, Jun 03, 2001 at 10:01:00PM -0400, Pete Zaitcev wrote:
> 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.
Good proposal, but how do you prevent the URB from being deleted by
unlink_urb when the completion works on this URB and has released the
list lock? This can of course only happen on SMP, but it is possible.
This is the sole purpose of the list lock, it wasn't there at the beginning.
It would be possible to transfer the lock to a static structure, to avoid
the usage after to completion...
> -- 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.
Your opinion. Have you checked that there are no races with unlink_urb and
transfer_result in uhci?
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
