> > > The problem is basically that the usbcore in case of an unlink has > > > to wait while the hardware might be dealing with an urb and the > > > completion handler is running. > > > > Classic urb-unlink issue inside the hcd, doesn't need > > to be exposed outside. Any given URB is either going > > to have completed normally, or be partially complete > > (including zero bytes), when the hardware stops work > > on it. The hcd only needs to report it appropriately. > > I really doubt that this issue can be not exposed.
And why is that? I just gave you an argument from first principles. You can't refute that by pointing to a bug in one current driver: > If I may point you to the following code path: > usb_unlink_urb -> sohci_unlink_urb > There you find a huge amount of usage of the urb pointer > the driver has supplied. When device drivers call usb_unlink_urb() with a pointer, they guarantee that the pointer is valid -- at least, the the urb hasn't been freed. While I do see a questionable use there (usb-ohci.c), that's also an area that's been cleaned up in the "ohci-hcd" driver. (The "ohci-hcd" part just does the hardware bits, while the more generic "hcd" part blocks till completion.) > Yet usb_unlink_urb and the completion handler can race, > at least on SMP. I can see really no way that API is supposed > to work if the urb can be freed in the completion handler. I could see that a driver which frees an urb in its completion handler _and_ keeps pointers to those urbs accessible to other driver code has a big design bug -- it has no good way to know if such pointers are still valid. No SMP needed. But you seem to be implying more than a bug in the driver design, and I can't see that. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
