Re: merge coming soon: jmcneill-usbmp

[Hans Petter Selasky <hselasky%c2i.net@localhost>]

On Tuesday 05 June 2012 19:59:08 matthew green wrote:
> >         - usbd_bus_methods{} gains a get_lock() to enable the
> >         
> >           host controller to provide a lock for the USB code.
> >           if the lock isn't provided, old-style protection is
> >           (partially) applied.
> > 
> > It is better if the USB driver can select the lock, like in FreeBSD. Else
> > you run into some atomic races when two SMP'enabled stacks are talking
> > to eachother, like a SMP-CAM layer and a SMP-USB stack.
> 

Hi,

> can you expand a little on what sort of races you mean?  for me, i
> originally helped with this effort so we could talk to the recently
> commited MP audio stack.

I can try to explain it a bit short.

If two SMP enabled stacks have each their lock, and they are calling each 
other, that means any callbacks must go unlocked, because else you can get a 
LOR (locking order reversal). Agree?

USB allows transactions to be cancelled. How can you exclude a callback from 
executing when it is being cancelled? Maybe you need one non-blocking cancel 
and a blocking cancel. Only the blocking cancel is allowed to wait for other 
threads to finish, and this is not the problem. The non-blocking version would 
need to do this by locking a non-sleepable mutex, and this is when the 
problems and possible races start. 

For example in case of fast open/close of character devices like /dev/ulptX, 
what will happen if a USB transfer is started and stopped in a loop really 
quick, assuming you don't allocate new transfers, but reuse existing ones.

Will the USB stack handle the calls so that the last call is the winning one? 
Or will the output be random?

> 
> > Has the FreeBSD's USB stack been evaluated when doing this NetBSD smp-ng,
> > or is this just a simple effort to try to get things a bit better than
> > is now?
> 
> the latter.  i'm not a USB person, and didn't really expect to come
> the owner of this project when i started helping :)  the TODO.usbmp
> has quite a few non trivial items in it, but those are more about
> enabling device-specific MP support at this point.
> 

--HPS