Re: New USB stack on FreeBSD w/Linux emulation layer coming

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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel