user/sven/linux.git/include/linux/hid.h, branch v3.10

HID: debug: fix RCU preemption issue

2013-05-06T11:07:33Z

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

Merge branch 'for-3.10/mt-hybrid-finger-pen' into for-linus

2013-04-30T08:17:48Z

Conflicts: drivers/hid/hid-multitouch.c

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:44Z

HID: protect hid_debug_list

2013-04-30T08:09:31Z

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: input: don't register unmapped input devices

2013-03-27T13:02:45Z

There is no need to register an input device containing no events. This allows drivers using the quirk MULTI_INPUT to register one input per report effectively used. For backward compatibility, we need to add a quirk to request this behavior. Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina

HID: ll_driver: Extend the interface with idle requests

2013-03-07T14:58:17Z

Some drivers send the idle command directly to underlying device, creating an unwanted dependency on the underlying transport layer. This patch adds hid_hw_idle() to the interface, thereby removing usbhid from the lion share of the drivers. Signed-off-by: Benjamin Tissoires Reviewed-by: David Herrmann Signed-off-by: Jiri Kosina

HID: Separate struct hid_device's driver_lock into two locks.

2013-03-01T13:13:07Z

This patch separates struct hid_device's driver_lock into two. The goal is to allow hid device drivers to receive input during their probe() or remove() function calls. This is necessary because some drivers need to communicate with the device to determine parameters needed during probe (e.g., size of a multi-touch surface), and if possible, may perfer to communicate with a device on host-initiated disconnect (e.g., to put it into a low-power state). Historically, three functions used driver_lock: - hid_device_probe: blocks to acquire lock - hid_device_remove: blocks to acquire lock - hid_input_report: if locked returns -EBUSY, else acquires lock This patch adds another lock (driver_input_lock) which is used to block input from occurring. The lock behavior is now: - hid_device_probe: blocks to acq. driver_lock, then driver_input_lock - hid_device_remove: blocks to acq. driver_lock, then driver_input_lock - hid_input_report: if driver_input_lock locked returns -EBUSY, else acquires driver_input_lock This patch also adds two helper functions to be called during probe() or remove(): hid_device_io_start() and hid_device_io_stop(). These functions lock and unlock, respectively, driver_input_lock; they also make a note of whether they did so that hid-core knows if a driver has changed the lock state. This patch results in no behavior change for existing devices and drivers. However, during a probe() or remove() function call in a driver, that driver may now selectively call hid_device_io_start() to let input events come through, then optionally call hid_device_io_stop() to stop them. Signed-off-by: Andrew de los Reyes Signed-off-by: Jiri Kosina

HID: Extend the interface with wait io request

2013-02-25T12:26:39Z

Some drivers need to wait for an io from the underlying device, creating an unwanted dependency on the underlying transport layer. This patch adds wait() to the interface, thereby removing usbhid from the lion share of the drivers. Signed-off-by: Henrik Rydberg Signed-off-by: Benjamin Tissoires Reviewed-by: Mika Westerberg Signed-off-by: Jiri Kosina

HID: Extend the interface with report requests

2013-02-25T12:26:39Z

Some drivers send reports directly to underlying device, creating an unwanted dependency on the underlying transport layer. This patch adds hid_hw_request() to the interface, thereby removing usbhid from the lion share of the drivers. Signed-off-by: Henrik Rydberg Signed-off-by: Benjamin Tissoires Reviewed-by: Mika Westerberg Signed-off-by: Jiri Kosina

Merge branches 'for-3.9/logitech', 'for-3.9/multitouch', 'for-3.9/ntrig', 'for-3.9/thingm' and 'for-3.9/upstream' into for-linus

2013-02-21T09:45:01Z