skipping locks, mutex_owned, usb

[John Baldwin]

On Sunday, August 28, 2011 5:27:44 am Hans Petter Selasky wrote:
> On Sunday 28 August 2011 11:25:51 Andriy Gapon wrote:
> > on 23/08/2011 15:09 Andriy Gapon said the following:
> > > This "XXX cludge" [sic] pattern is scattered around a few functions in
> > > the ukbd code and perhaps other usb code:
> > > func()
> > > {
> > > 
> > > 	if (!mtx_owned(&Giant)) {
> > > 	
> > > 		mtx_lock(&Giant);
> > > 		
> > >                 func();
> > >                 mtx_unlock(&Giant);
> > > 		
> > > 		return;
> > > 	
> > > 	}
> > > 	
> > > 	// etc ...
> > > 
> > > }
> > 
> > Ohhh, nothing seems simple with the USB code:
> > 
> > /* make sure that the BUS mutex is not locked */
> > drop_bus = 0;
> > while (mtx_owned(&xroot->udev->bus->bus_mtx)) {
> >         mtx_unlock(&xroot->udev->bus->bus_mtx);
> >         drop_bus++;
> > }
> > 
> > /* make sure that the transfer mutex is not locked */
> > drop_xfer = 0;
> > while (mtx_owned(xroot->xfer_mtx)) {
> >         mtx_unlock(xroot->xfer_mtx);
> >         drop_xfer++;
> > }
> > 
> > So many unconventional tricks.
> 
> Similar code is used in the DROP_GIANT and PICKUP_GIANT macros. You might 
want 
> to check all references to mtx_owned() in the kernel, and make a set of 
> exceptions for post-panic code execution.

Giant is special because it is a hack to let us run non-MPSAFE code.  Other
locks should not follow its model.

-- 
John Baldwin