linux.git/drivers/hid/hid-core.c, branch v3.10

HID: debug: fix RCU preemption issue

2013-05-06T11:07:33+00:00

Commit 2353f2bea ("HID: protect hid_debug_list") introduced mutex
locking around debug_list access to prevent SMP races when debugfs
nodes are being operated upon by multiple userspace processess.

mutex is not a proper synchronization primitive though, as the hid-debug
callbacks are being called from atomic contexts.

We also have to be careful about disabling IRQs when taking the lock
to prevent deadlock against IRQ handlers.

Benjamin reports this has also been reported in RH bugzilla as bug #958935.

 ===============================
 [ INFO: suspicious RCU usage. ]
 3.9.0+ #94 Not tainted
 -------------------------------
 include/linux/rcupdate.h:476 Illegal context switch in RCU read-side critical section!

 other info that might help us debug this:

 rcu_scheduler_active = 1, debug_locks = 0
 4 locks held by Xorg/5502:
  #0:  (&evdev->mutex){+.+...}, at: [] evdev_write+0x6d/0x160
  #1:  (&(&dev->event_lock)->rlock#2){-.-...}, at: [] input_inject_event+0x5b/0x230
  #2:  (rcu_read_lock){.+.+..}, at: [] input_inject_event+0x42/0x230
  #3:  (&(&usbhid->lock)->rlock){-.....}, at: [] usb_hidinput_input_event+0x89/0x120

 stack backtrace:
 CPU: 0 PID: 5502 Comm: Xorg Not tainted 3.9.0+ #94
 Hardware name: Dell Inc. OptiPlex 390/0M5DCD, BIOS A09 07/24/2012
  0000000000000001 ffff8800689c7c38 ffffffff816f249f ffff8800689c7c68
  ffffffff810acb1d 0000000000000000 ffffffff81a03ac7 000000000000019d
  0000000000000000 ffff8800689c7c90 ffffffff8107cda7 0000000000000000
 Call Trace:
  [] dump_stack+0x19/0x1b
  [] lockdep_rcu_suspicious+0xfd/0x130
  [] __might_sleep+0xc7/0x230
  [] mutex_lock_nested+0x40/0x3a0
  [] ? vsnprintf+0x354/0x640
  [] hid_debug_event+0x34/0x100
  [] hid_dump_input+0x67/0xa0
  [] hid_set_field+0x50/0x120
  [] usb_hidinput_input_event+0x9a/0x120
  [] input_handle_event+0x8e/0x530
  [] input_inject_event+0x1d0/0x230
  [] ? input_inject_event+0x42/0x230
  [] evdev_write+0xde/0x160
  [] vfs_write+0xc8/0x1f0
  [] SyS_write+0x55/0xa0
  [] system_call_fastpath+0x16/0x1b
 BUG: sleeping function called from invalid context at kernel/mutex.c:413
 in_atomic(): 1, irqs_disabled(): 1, pid: 5502, name: Xorg
 INFO: lockdep is turned off.
 irq event stamp: 1098574
 hardirqs last  enabled at (1098573): [] _raw_spin_unlock_irqrestore+0x3f/0x70
 hardirqs last disabled at (1098574): [] _raw_spin_lock_irqsave+0x25/0xa0
 softirqs last  enabled at (1098306): [] __do_softirq+0x18f/0x3c0
 softirqs last disabled at (1097867): [] irq_exit+0xa5/0xb0
 CPU: 0 PID: 5502 Comm: Xorg Not tainted 3.9.0+ #94
 Hardware name: Dell Inc. OptiPlex 390/0M5DCD, BIOS A09 07/24/2012
  ffffffff81a03ac7 ffff8800689c7c68 ffffffff816f249f ffff8800689c7c90
  ffffffff8107ce60 0000000000000000 ffff8800689c7fd8 ffff88006a62c800
  ffff8800689c7d10 ffffffff816f7770 ffff8800689c7d00 ffffffff81312ac4
 Call Trace:
  [] dump_stack+0x19/0x1b
  [] __might_sleep+0x180/0x230
  [] mutex_lock_nested+0x40/0x3a0
  [] ? vsnprintf+0x354/0x640
  [] hid_debug_event+0x34/0x100
  [] hid_dump_input+0x67/0xa0
  [] hid_set_field+0x50/0x120
  [] usb_hidinput_input_event+0x9a/0x120
  [] input_handle_event+0x8e/0x530
  [] input_inject_event+0x1d0/0x230
  [] ? input_inject_event+0x42/0x230
  [] evdev_write+0xde/0x160
  [] vfs_write+0xc8/0x1f0
  [] SyS_write+0x55/0xa0
  [] system_call_fastpath+0x16/0x1b

Reported-by: majianpeng 
Reported-by: Benjamin Tissoires 
Reviewed-by: Dmitry Torokhov 
Signed-off-by: Jiri Kosina

HID: reintroduce fix-up for certain Sony RF receivers

2013-05-01T12:58:14+00:00

It looks like the manual merge 0d69a3c731e120b05b7da9fb976830475a3fbc01 ("Merge
branches 'for-3.9/sony' and 'for-3.9/steelseries' into for-linus") accidentally
removed Sony RF receiver with USB product id 0x0374 from the "have special
driver" list, effectively nullifying a464918419f94a0043d2f549d6defb4c3f69f68a
("HID: add support for Sony RF receiver with USB product id 0x0374"). Add the
device back to the list.

Cc: stable@vger.kernel.org
Signed-off-by: Fernando Luis Vazquez Cao 
Signed-off-by: Jiri Kosina

Merge branches 'for-3.10/wiimote' and 'for-3.9/upstream-fixes' into for-linus

2013-04-30T08:19:21+00:00

Merge branches 'for-3.10/multitouch', 'for-3.10/roccat' and 'for-3.10/upstream' into for-linus

2013-04-30T08:19:07+00:00

Conflicts:
	drivers/hid/Kconfig

Merge branches 'for-3.10/appleir', 'for-3.10/hid-debug', 'for-3.10/hid-driver-transport-cleanups', 'for-3.10/i2c-hid' and 'for-3.10/logitech' into for-linus

2013-04-30T08:12:44+00:00

HID: protect hid_debug_list

2013-04-30T08:09:31+00:00

Accesses to hid_device->hid_debug_list are not serialized properly, which
could result in SMP concurrency issues when HID debugfs events are accessesed
by multiple userspace processess.

Serialize all the list operations by a mutex.

Spotted by Al Viro.

Signed-off-by: Jiri Kosina

HID: debug: break out hid_dump_report() into hid-debug

2013-04-30T08:09:06+00:00

No semantic changes, but hid_dump_report should be in hid-debug.c, not
in hid-core.c

Signed-off-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: Add PID for Japanese version of NE4K keyboard

2013-04-29T08:16:55+00:00

This patche adds PID of Japanese Natual Ergonomic Keyboard 4000. HID
NE4K driver depends on this PID for determining its quirks. F14-F18 keys
would not work without the patch.

Signed-off-by: Adam Jiang 
Signed-off-by: Jiri Kosina

HID: appleir: add support for Apple ir devices

2013-04-19T02:06:20+00:00

This driver was originally written by James McKenzie, updated by
Greg Kroah-Hartman, further updated by Bastien Nocera, with suspend
support added.
I ported it to the HID subsystem, in order to simplify it a litle
and allow lirc to use it through hiddev.

More recent versions of the IR receiver are also supported through
a patch by Alex Karpenko. The patch also adds support for the 2nd
and 5th generation of the controller, and the menu key on newer
brushed metal remotes.

Tested-by: Fabien André 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: wiimote: add 2nd generation Wii Remote IDs

2013-04-04T07:38:43+00:00

This adds the 2nd generation Wii Remote IDs. They have a different
Bluetooth chipset (CSR instead of Broadcom) and are more restrictive in
what they accept as input. Hence, you need up-to-date BlueZ and
Bluetooth HIDP modules to use these devices.

Signed-off-by: David Herrmann 
Signed-off-by: Jiri Kosina