Re: [PATCH 5/8] [media] em28xx: initial support for HAUPPAUGE HVR-930C again

[Mauro Carvalho Chehab <mchehab@redhat.com>]

On 06-12-2011 13:28, Mark Lord wrote:
> On 11-12-06 08:56 AM, Devin Heitmueller wrote:
>> On Tue, Dec 6, 2011 at 8:43 AM, Mauro Carvalho Chehab
>> <mchehab@redhat.com>  wrote:
>>> The driver who binds everything is the bridge driver. In your case, it is
>>> the au0828 driver.
>>>
>>> What you're experiencing seems to be some race issue inside it, and not at
>>> xc5000.
>>>
>>> On a quick look on it, I'm noticing that there's no lock at
>>> au0828_usb_probe().
>>>
>>> Also, it uses a separate lock for analog and for digital:
>>>
>>>         mutex_init(&dev->mutex);
>>>         mutex_init(&dev->dvb.lock);
>>>
>>> Probably, the right thing to do would be to use just one lock for both
>>> rising
>>> it at usb_probe, lowering it just before return 0. This will avoid any open
>>> operations while the device is not fully initialized. Btw, newer udev's open
>>> the analog part of the driver just after V4L register, in order to get the
>>> device capabilities. This is known to cause race conditions, if the locking
>>> schema is not working properly.
>>
>> Just to be clear, we're now talking about a completely different race
>> condition that has nothing to do with the subject at hand, and this
>> discussion should probably be moved to a new thread.
>
> If this discussion does change threads, could you folks please copy me
> on it?  I'm already subscribed to several other kernel mailing lists
> in my roles as developer and maintainer of various bits, but I would
> like to avoid having yet another daily deluge added to my inbox.  :)
>
> That said, I can test possible fixes for this stuff,
> and am rather interested to see it resolved.
> ..
>> The notion that this is something that has been there for over a year
>> is something I only learned of in the last couple of days.  All the
>> complaints I had seen thus far were from existing users who were
>> perfectly happy until they upgraded their kernel a couple of months
>> ago and then started seeing the problem.
> ..
>
> It's always exhibited races for me here.  I have long since worked around
> the issue(s), so my own systems currently behave.   But with the newer
> HVR-950Q revision (B4F0), the issue is far more prevalent than before.
>
> I may try Mauro's locking suggestion -- more detail or a patch would be useful.

You may take a look at the lock changes applied on em28xx driver for some examples.
You basically need to block access to DVB while the device is handling a V4L syscall
and vice-versa.

Changing the locking schema is not trivial, as it may generate dead locks. So,
careful testing is required. It also helps to compile a kernel with the dead lock
detection logic enabled, as it may help you to discover if you did something wrong.

Regards,
Mauro

>
> Mauro?