[pvrusb2] driver lock circular dependency :-(

[Mike Isely]

Folks:

The in-kernel pvrusb2 driver has an issue which results in a race that can 
trip up the kernel's circular lock detector.  Thanks go to Helmut 
Toplitzer for being the unwitting victim who hit it first.  If you see 
something similar to this in your log:

> =======================================================
> [ INFO: possible circular locking dependency detected ]
> -------------------------------------------------------
> mythbackend/2974 is trying to acquire lock:
>  (device_lock){--..}, at: [<c029452c>] mutex_lock+0x12/0x15
>
> but task is already holding lock:
>  (videodev_lock){--..}, at: [<c029452c>] mutex_lock+0x12/0x15
>
> which lock already depends on the new lock.

(substitute whatever V4L app you're running for "mythbackend")

Then you've hit the issue.  The names "device_lock" and "videodev_lock" 
are the telltale signs in the message.  This is a race that can happen if 
the app attempts to open the device before the driver has finished 
initializing its V4L interface.  The problem was introduced in 2.6.18 as a 
result of a V4L-required change I had to implement involving the pvrusb2 
driver and storing of a context pointer.  Theoretically this race can 
cause a deadlock in the app.  You're at risk for this if you are running 
the in-V4L pvrusb2 driver or if you are running any pvrusb2 driver version 
under the 2.6.18 kernel.

Obviously a fix for this needs to be submitted.  I'm still working on 
that.  In the mean time, you can avoid the problem in this manner:

Step 1. Use the standalone driver (any recent snapshot will do).  You can 
just rename the kernel-built pvrusb2.ko out of the way - no need to 
rebuild the kernel.

Step 2. Edit driver/compat.h, and comment out any spot within it which 
defines the macro "PVR2_ENABLE_V4LDEVTRACK".

The PVR2_ENABLE_V4LDEVTRACK macro, when set, disables the driver's use of 
a context pointer in the video_device structure and substitutes a private 
global array for tracking the same data.  I had implemented this change 
because that context pointer feature is going away in V4L (though right 
now I think I can make a strong case for why that is a bad idea...).  
Unfortunately as with any global data, it needs to be protected with a 
mutex, and the required operation of that mutex is conflicting with 
another mutex in the V4L core, which then trips the circular lock 
detection in the kernel.  So, by disabling PVR2_ENABLE_V4LDEVTRACK, you go 
back to the "old" way of doing this, which doesn't need this mutex, which 
still works for the 2.6.18 kernel.

You have to use the standalone driver to do this because the other two 
versions (in-kernel and in-V4L) are physically stripped down for their 
corresponding environment in which they live.  The standalone driver on 
the other hand has to work everywhere, which is why switches like this are 
in it.  So grab the standalone driver, turn off PVR2_ENABLE_V4LDEVTRACK, 
and you won't hit this problem.

Sorry about this.  It's not my fault!  (said Han Solo...)  :-) :-)

  -Mike


-- 
                        |         Mike Isely          |     PGP fingerprint
     Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                        |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                        |                             |