On Wednesday 16 May 2007, Hans Petter Selasky wrote: > Hi, > > On Wednesday 16 May 2007 20:20, David Brownell wrote: > > > > > > URB submission has other failure possibilities than lack of memory. > > > > > > Those other things have to be checked for regardless. > > > > > > > > > > Yes, but that is because you allow too many parameters in the URB to > > > > > be changed between USB transfers. > > > > > > > > No; it's because unforeseen events can occur. For example, the device > > > > may have been unplugged or suspended. > > > > > > On FreeBSD it will never happen that you call the equivalent > > > of "usb_submit_urb()" after that the device has detached! It must be > > > something terribly wrong in the Linux USB stack if the callbacks are > > > alive after that you have detached a USB device. > > > > How does that work then ... driver must grab a lock, check > > whether the device has disconnected, then submit the request > > and drop the lock? Sounds like needless slowdowns. > > Each USB device has its own lock. There are some tricks there. > > 1) usbd_transfer_start() is always called like this: > usbd_transfer_start(sc->sc_xfer[x]); > > 2) sc->sc_xfer[x] is set to zero at detach holding the private lock of the > USB > device driver. All subsequent calls to usbd_transfer_start(), if any, will > fail.
So there's a race on SMP, where sc->sc_xfer[x] may be referenced on one CPU while another is nulling it. The lock you showed is inside usbd_transfer_start(), where it can't do any good. > 3) usbd_transfer_start() is always non-blocking. In other words a single lock > is held across the call. Like usb_submit_urb() then, except that the disconnect race is handled by being buggy rather than by reporting a fault at submit time... > ... > > > > Because if there's no lock against async disconnect events, > > then it's trivial to have the disconnect logic underway on > > one CPU while another CPU does real work, submitting an I/O > > request. > > We solve this in one of two ways: > > 1) Using a mutex. At detach we lock the mutex stopping all transfers. > > 2) Using a thread. At detach we teardown and wait for the thread to exit. But there's that race above, so it's not "solved". - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
