> Date: Thu, 17 Jul 2003 18:39:38 -0700 > From: David Brownell <[EMAIL PROTECTED]>
> > So the completion uses an extra field to indicate that > > urb was released by HC driver to the uppper level. > > It's not an explicit field, it's an extra field. > > This really makes no sense to me. There's a field, with > an SMP-safe lock. The protocol between one layer and > the next involves holding that lock before changing that > field. And you're saying that's racey. How? The urb->lock is situated in the same chunk of storage as the urb->status, so it only can protect the status if there is no hazard of deallocation of the urb. However, our API makes no such guarantees across the call to the ->complete. Therefore, urb->lock cannot be held across the callback. Once it cannot be held across the callback, there is a window for the upper layer to peek at the urb after the end of transfer and before the calback proper, and then it's an oops. This is basically the reason urb->lock useage was thrown out of usb-uhci by Georg (upon my insistence). And the worst part is what YOU personally went through several rounts of patching of usb-uhci, we had all this situation with Dell and bunch of bugs with oopses. And now you do not remember why usb-uhci is so superior and why urb->lock should have been thrown out of the struct urb long time ago. -- Pete ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
