linux/drivers/input/evdev.c, branch v3.12.14

Input: evdev - fall back to vmalloc for client event buffer

2013-12-04T19:06:07Z

commit 92eb77d0ffbaa71b501a0a8dabf09a351bf4267f upstream. evdev always tries to allocate the event buffer for clients using kzalloc rather than vmalloc, presumably to avoid mapping overhead where possible. However, drivers like bcm5974, which claims support for reporting 16 fingers simultaneously, can have an extraordinarily large buffer. The resultant contiguous order-4 allocation attempt fails due to fragmentation, and the device is thus unusable until reboot. Try kzalloc if we can to avoid the mapping overhead, but if that fails, fall back to vzalloc. Signed-off-by: Daniel Stone Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: evdev - add EVIOCREVOKE ioctl

2013-09-07T19:53:20Z

If we have multiple sessions on a system, we normally don't want background sessions to read input events. Otherwise, it could capture passwords and more entered by the user on the foreground session. This is a real world problem as the recent XMir development showed: http://mjg59.dreamwidth.org/27327.html We currently rely on sessions to release input devices when being deactivated. This relies on trust across sessions. But that's not given on usual systems. We therefore need a way to control which processes have access to input devices. With VTs the kernel simply routed them through the active /dev/ttyX. This is not possible with evdev devices, though. Moreover, we want to avoid routing input-devices through some dispatcher-daemon in userspace (which would add some latency). This patch introduces EVIOCREVOKE. If called on an evdev fd, this revokes device-access irrecoverably for that *single* open-file. Hence, once you call EVIOCREVOKE on any dup()ed fd, all fds for that open-file will be rather useless now (but still valid compared to close()!). This allows us to pass fds directly to session-processes from a trusted source. The source keeps a dup()ed fd and revokes access once the session-process is no longer active. Compared to the EVIOCMUTE proposal, we can avoid the CAP_SYS_ADMIN restriction now as there is no way to revive the fd again. Hence, a user is free to call EVIOCREVOKE themself to kill the fd. Additionally, this ioctl allows multi-layer access-control (again compared to EVIOCMUTE which was limited to one layer via CAP_SYS_ADMIN). A middle layer can simply request a new open-file from the layer above and pass it to the layer below. Now each layer can call EVIOCREVOKE on the fds to revoke access for all layers below, at the expense of one fd per layer. There's already ongoing experimental user-space work which demonstrates how it can be used: http://lists.freedesktop.org/archives/systemd-devel/2013-August/012897.html Signed-off-by: David Herrmann Signed-off-by: Dmitry Torokhov

Input: evdev - flush queues during EVIOCGKEY-like ioctls

2013-06-10T05:35:05Z

If userspace requests current KEY-state, they very likely assume that no such events are pending in the output queue of the evdev device. Otherwise, they will parse events which they already handled via EVIOCGKEY(). For XKB applications this can cause irreversible keyboard states if a modifier is locked multiple times because a CTRL-DOWN event is handled once via EVIOCGKEY() and once from the queue via read(), even though it should handle it only once. Therefore, lets do the only logical thing and flush the evdev queue atomically during this ioctl. We only flush events that are affected by the given ioctl. This only affects boolean events like KEY, SND, SW and LED. ABS, REL and others are not affected as duplicate events can be handled gracefully by user-space. Note: This actually breaks semantics of the evdev ABI. However, investigations showed that userspace already expects the new semantics and we end up fixing at least all XKB applications. All applications that are aware of this race-condition mirror the KEY state for each open-file and detect/drop duplicate events. Hence, they do not care whether duplicates are posted or not and work fine with this fix. Also note that we need proper locking to guarantee atomicity and avoid dead-locks. event_lock must be locked before queue_lock (see input-core). However, we can safely release event_lock while flushing the queue. This allows the input-core to proceed with pending events and only stop if it needs our queue_lock to post new events. This should guarantee that we don't block event-dispatching for too long while flushing a single event queue. Signed-off-by: David Herrmann Acked-by: Peter Hutterer Signed-off-by: Dmitry Torokhov

Input: fix use-after-free introduced with dynamic minor changes

2012-10-22T05:50:37Z

Commit 7f8d4cad1e4e ("Input: extend the number of event (and other) devices") made evdev, joydev and mousedev to embed struct cdev into their respective structures representing input devices. Unfortunately character device structure may outlive the parent structure unless we do not set it up as parent of character device so that it will stay pinned until character device is freed. Also, now that parent structure is pinned while character device exists we do not need to pin and unpin it every time user opens or closes it. Reported-by: Dave Jones Signed-off-by: Dmitry Torokhov Acked-by: Al Viro Signed-off-by: Linus Torvalds

Input: extend the number of event (and other) devices

2012-10-08T16:37:55Z

Extend the amount of character devices, such as eventX, mouseX and jsX, from a hard limit of 32 per input handler to about 1024 shared across all handlers. To be compatible with legacy installations input handlers will start creating char devices with minors in their legacy range, however once legacy range is exhausted they will start allocating minors from the dynamic range 256-1024. Reviewed-by: David Herrmann Signed-off-by: Dmitry Torokhov

Input: evdev - Add the events() callback

2012-09-19T17:50:18Z

By sending a full frame of events at the same time, the irqsoff latency at heavy load is brought down from 200 us to 100 us. Cc: Daniel Kurtz Tested-by: Benjamin Tissoires Tested-by: Ping Cheng Acked-by: Dmitry Torokhov Signed-off-by: Henrik Rydberg

Input: Break out MT data

2012-09-19T17:50:17Z

Move all MT-related things to a separate place. This saves some bytes for non-mt input devices, and prepares for new MT features. Reviewed-and-tested-by: Benjamin Tissoires Tested-by: Ping Cheng Acked-by: Dmitry Torokhov Signed-off-by: Henrik Rydberg

Input: evdev - properly handle read/write with count 0

2012-05-02T07:23:58Z

According to the standard count 0 is special - no IO should happen but we can check error conditions (device gone away, etc), and return 0 if there are no errors. We used to return -EINVAL instead and we also could return 0 if an event was "stolen" by another thread. Signed-off-by: Dmitry Torokhov

Input: evdev - properly access RCU-protected 'grab' data

2012-05-02T07:23:14Z

We should use rcu_dereference_protected() when checking if given client is the one that grabbed the device. This fixes warnings produced by sparse. Signed-off-by: Dmitry Torokhov

Merge branch 'next' into for-linus

2012-03-20T00:02:01Z