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

> > > > > 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.
> > >
> > > ...
> >
> > 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.
> 
> It is an assert statement. The "priv_mtx" lock must be locked before you call 
> usbd_transfer_start(). There is no race on SMP.

I see; I was expecting a response like "yes, driver must grab
lock" and that step was omitted from your response.



> If you need to do Async stuff, then you have to do it in a separate thread or 
> in a so-called task-queue. Else you are in for great trouble! That was the 
> big "sin" in the old USB stack on FreeBSD: Calling synchronous USB callbacks 
> from everywhere, like ioctl/read/write - callbacks.
> 
> Is that a problem on Linux also?

All callbacks are async.  At one point there were some bugs associated
with callers that accidentally placed racey restrictions on when the
callbacks could occur -- i.e. expected them at some point after a call
returned, rather than any point after the call was issued -- but such
bugs seem to be largely fixed now.  (Hard to be sure though.)


> On Linux I see no locks used in the USB drivers,

Look again, then!  Driver-private locks are all over the place.


> so they are solely protected by interrupt-level mechanisms.

Maybe you mean "caller-transparent mechanisms"?  Synchronous
calls use mutexes (or for old code, semaphores) internally.
Async ones use spinlocks.


> My rule is that: Synchronous or blocking calls _must_ happen in a config 
> thread that you can wait for. Else asynchronous calls on pre-allocated 
> transfers can happen anywhere.

Well *obviously* blocking calls require a schedulable context,
and others don't.  We don't restrict things to "config" threads.


> The problem clearly appears on Linux SMP because:
> 
> a) No locks are in the USB drivers (then they must be all so-called "Giant" 
> locked)

Nope; I don't have an idea why you overlook all the mutex
and spinlock calls in the drivers.  There's the legacy
"big kernel lock" but not much uses that any more.


> b) You don't pre-allocate transfers, resulting in synchronous/blocking calls 
> everywhere, and no-one thinks about what can happen then :-)

You should learn more about the stack before making such
sweeping (and wrong) statements.

- 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