linux-stable.git/drivers/media, branch linux-2.6.38.y

cx88: hold device lock during sub-driver initialization

2011-06-03T01:34:29+00:00

commit 1d6213ab995c61f7d1d81cf6cf876acf15d6e714 upstream.

cx8802_blackbird_probe makes a device node for the mpeg sub-device
before it has been added to dev->drvlist.  If the device is opened
during that time, the open succeeds but request_acquire cannot be
called, so the reference count remains zero.  Later, when the device
is closed, the reference count becomes negative --- uh oh.

Close the race by holding core->lock during probe and not releasing
until the device is in drvlist and initialization finished.
Previously the BKL prevented this race.

Reported-by: Andreas Huber 
Tested-by: Andi Huber 
Tested-by: Marlon de Boer 
Signed-off-by: Jonathan Nieder 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

cx88: fix locking of sub-driver operations

2011-06-03T01:34:28+00:00

commit 1fe70e963028f34ba5e32488a7870ff4b410b19b upstream.

The BKL conversion of this driver seems to have gone wrong.
Loading the cx88-blackbird driver deadlocks.

The cause: mpeg_ops::open in the cx2388x blackbird driver acquires the
device lock and calls the sub-driver's request_acquire, which tries to
acquire the lock again.  Fix it by clarifying the semantics of
request_acquire, request_release, advise_acquire, and advise_release:
now all will rely on the caller to acquire the device lock.

Based on work by Ben Hutchings .

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=31962

Reported-by: Andi Huber 
Tested-by: Andi Huber 
Tested-by: Marlon de Boer 
Signed-off-by: Jonathan Nieder 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

cx88: protect per-device driver list with device lock

2011-06-03T01:34:28+00:00

commit 8a317a8760cfffa8185b56ff59fb4b6c58488d79 upstream.

The BKL conversion of this driver seems to have gone wrong.  Various
uses of the sub-device and driver lists appear to be subject to race
conditions.

In particular, some functions access drvlist without a relevant lock
held, which will race against removal of drivers.  Let's start with
that --- clean up by consistently protecting dev->drvlist with
dev->core->lock, noting driver functions that require the device lock
to be held or not to be held.

After this patch, there are still some races --- e.g.,
cx8802_blackbird_remove can run between the time the blackbird driver
is acquired and the time it is used in mpeg_release, and there's a
similar race in cx88_dvb_bus_ctrl.  Later patches will address the
remaining known races and the deadlock noticed by Andi.  This patch
just makes the semantics clearer in preparation for those later
changes.

Based on work by Ben Hutchings .

Tested-by: Andi Huber 
Tested-by: Marlon de Boer 
Signed-off-by: Jonathan Nieder 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

v4l: Release module if subdev registration fails

2011-05-21T22:13:31+00:00

commit b7534f002d3c81d18abfbf57179d07d3ec763bb5 upstream.

If v4l2_device_register_subdev() fails, the reference to the subdev
module taken by the function isn't released. Fix this.

Signed-off-by: Laurent Pinchart 
Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

Fix cx88 remote control input

2011-05-21T22:13:31+00:00

commit 2a164d02dd34c6b49a3f0995900e0f8af102b804 upstream.

In the IR interrupt handler of cx88-input.c there's a 32-bit multiply
overflow which causes IR pulse durations to be incorrectly calculated.

This is a regression caused by commit 2997137be8eba.

Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

cx88: Fix HVR4000 IR keymap

2011-05-09T22:06:49+00:00

[fixed in .39 in a much different way that is too big to backport to
.38 - gregkh]

Fixes the RC key input for Nova-S plus, HVR1100, HVR3000 and HVR4000 in
the 2.6.38 kernel.

Signed-off-by: Lawrence Rust 
Acked-by: Jarod Wilson 
Signed-off-by: Mauro Carvalho Chehab

imon: add conditional locking in change_protocol

2011-05-09T22:06:43+00:00

commit 23ef710e1a6c4d6b9ef1c2fa19410f7f1479401e upstream.

The imon_ir_change_protocol function gets called two different ways, one
way is from rc_register_device, for initial protocol selection/setup,
and the other is via a userspace-initiated protocol change request,
either by direct sysfs prodding or by something like ir-keytable.

In the rc_register_device case, the imon context lock is already held,
but when initiated from userspace, it is not, so we must acquire it,
prior to calling send_packet, which requires that the lock is held.

Without this change, there's an easily reproduceable deadlock when
another function calls send_packet (such as either of the display write
fops) after a userspace-initiated change_protocol.

With a lock-debugging-enabled kernel, I was getting this:

[   15.014153] =====================================
[   15.015048] [ BUG: bad unlock balance detected! ]
[   15.015048] -------------------------------------
[   15.015048] ir-keytable/773 is trying to release lock (&ictx->lock) at:
[   15.015048] [] mutex_unlock+0xe/0x10
[   15.015048] but there are no more locks to release!
[   15.015048]
[   15.015048] other info that might help us debug this:
[   15.015048] 2 locks held by ir-keytable/773:
[   15.015048]  #0:  (&buffer->mutex){+.+.+.}, at: [] sysfs_write_file+0x3c/0x144
[   15.015048]  #1:  (s_active#87){.+.+.+}, at: [] sysfs_write_file+0xe7/0x144
[   15.015048]
[   15.015048] stack backtrace:
[   15.015048] Pid: 773, comm: ir-keytable Not tainted 2.6.38.4-20.fc15.x86_64.debug #1
[   15.015048] Call Trace:
[   15.015048]  [] ? print_unlock_inbalance_bug+0xca/0xd5
[   15.015048]  [] ? lock_release_non_nested+0xc1/0x263
[   15.015048]  [] ? mutex_unlock+0xe/0x10
[   15.015048]  [] ? mutex_unlock+0xe/0x10
[   15.015048]  [] ? lock_release+0x17d/0x1a4
[   15.015048]  [] ? __mutex_unlock_slowpath+0xc5/0x125
[   15.015048]  [] ? mutex_unlock+0xe/0x10
[   15.015048]  [] ? send_packet+0x1c9/0x264 [imon]
[   15.015048]  [] ? lock_release_non_nested+0xdb/0x263
[   15.015048]  [] ? imon_ir_change_protocol+0x126/0x15e [imon]
[   15.015048]  [] ? store_protocols+0x1c3/0x286 [rc_core]
[   15.015048]  [] ? dev_attr_store+0x20/0x22
[   15.015048]  [] ? sysfs_write_file+0x108/0x144
...

The original report that led to the investigation was the following:

[ 1679.457305] INFO: task LCDd:8460 blocked for more than 120 seconds.
[ 1679.457307] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1679.457309] LCDd            D ffff88010fcd89c8     0  8460      1 0x00000000
[ 1679.457312]  ffff8800d5a03b48 0000000000000082 0000000000000000 ffff8800d5a03fd8
[ 1679.457314]  00000000012dcd30 fffffffffffffffd ffff8800d5a03fd8 ffff88010fcd86f0
[ 1679.457316]  ffff8800d5a03fd8 ffff8800d5a03fd8 ffff88010fcd89d0 ffff8800d5a03fd8
[ 1679.457319] Call Trace:
[ 1679.457324]  [] ? zone_statistics+0x75/0x90
[ 1679.457327]  [] ? get_page_from_freelist+0x3c7/0x820
[ 1679.457330]  [] __mutex_lock_slowpath+0x139/0x320
[ 1679.457335]  [] mutex_lock+0x11/0x30
[ 1679.457338]  [] display_open+0x66/0x130 [imon]
[ 1679.457345]  [] usb_open+0x180/0x310 [usbcore]
[ 1679.457349]  [] chrdev_open+0x1bb/0x2d0
[ 1679.457350]  [] __dentry_open+0x10d/0x370
[ 1679.457352]  [] ? chrdev_open+0x0/0x2d0
...

Bump the driver version here so its easier to tell if people have this
locking fix or not, and also make locking during probe easier to follow.

Reported-by: Benjamin Hodgetts 
Signed-off-by: Jarod Wilson 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

v4l: make sure drivers supply a zeroed struct v4l2_subdev

2011-05-09T22:06:43+00:00

commit 80845a33165278f3236812009e9c568ba8c29938 upstream.

Some v4l drivers currently don't initialize their struct v4l2_subdev
with zeros, and this is a problem since some of the v4l2 code expects
this. One example is the addition of internal_ops in commit 45f6f84,
after that we are at risk of random oopses with these drivers when code
in v4l2_device_register_subdev tries to dereference sd->internal_ops->*,
as can be shown by the report at http://bugs.launchpad.net/bugs/745213
and analysis of its crash at https://lkml.org/lkml/2011/4/1/168

Use kzalloc within problematic drivers to ensure we have a zeroed struct
v4l2_subdev.

BugLink: http://bugs.launchpad.net/bugs/745213
Signed-off-by: Herton Ronaldo Krzesinski 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

FLEXCOP-PCI: fix __xlate_proc_name-warning for flexcop-pci

2011-05-02T16:19:44+00:00

commit b934c20de1398d4a82d2ecfeb588a214a910f13f upstream.

This patch fixes the warning about bad names for sys-fs and other kernel-things. The flexcop-pci driver was using '/'-characters in it, which is not good.
This has been fixed in several attempts by several people, but obviously never made it into the kernel.

Signed-off-by: Patrick Boettcher 
Cc: Steffen Barszus 
Cc: Boris Cuber 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

video: sn9c102: world-wirtable sysfs files

2011-04-21T21:32:21+00:00

commit 14ddc3188d50855ae2a419a6aced995e2834e5d4 upstream.

Don't allow everybody to change video settings.

Signed-off-by: Vasiliy Kulikov 
Acked-by: Mauro Carvalho Chehab 
Acked-by: Luca Risolia 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman