[pvrusb2] pvrusb2 driver lock in 2.6.27: workaround

[Mike Isely]

On Sat, 18 Oct 2008, Mike Isely wrote:

> I need to go back and study older kernels to see why this wasn't a 
> problem before 2.6.27.  Once I have a better handle on this, I'll 
> concoct a patch to fix it permanently.
> 

I found the difference.  Older kernels had different behavior when a USB 
device reset request was issued to the USB core.

Previously the USB reset took place "in line", meaning that the reset 
request was executed by the USB core and control returned back to the 
caller, with no other state "disturbed".  Specifically, the USB device 
remained connected and the driver instance still had control of it.

With kernel 2.6.27, calling into the USB core to request a device reset 
triggers a USB disconnect / reconnect - and the disconnect callback to 
the driver happens on the same stack (i.e. thread context) as the caller 
which issued the reset request.  Doing that callback piggybacked on top 
of the driver's own call into the USB core sets up the deadlock in the 
driver.

However, even if the callback had come from another thread context we'd 
still be screwed: In that case the driver would happily disconnect, then 
it would get the reconnect as one might expect.  And then... the driver 
would simply have issued another USB reset request as part of the new 
initialization.  Lather, rinse repeat...

Clearly it's no longer safe for the driver to trigger any kind of USB 
device reset and still hope to hang onto the device it is controlling.  
I will eliminate the initusbreset behavior completely.  If anyone thinks 
this might be a bad idea (does someone thinks he/she is depending on 
it?), please tell me now.

  -Mike


-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8