Input: uinput - fix race that can block nonblocking read
authorDmitry Torokhov <dmitry.torokhov@gmail.com>
Mon, 30 Jul 2012 05:48:31 +0000 (22:48 -0700)
committerDmitry Torokhov <dmitry.torokhov@gmail.com>
Wed, 22 Aug 2012 05:29:53 +0000 (22:29 -0700)
commit22ae19c6e3c22b390952e90f452f26adad9b8687
tree2de61c0c509f60e38306fad5b523e2b11420d134
parentf40033acc2d14acecd1b27a79dc8a0ad437e619a
Input: uinput - fix race that can block nonblocking read

Consider two threads calling read() on the same uinput-fd, both
non-blocking. Assume there is data-available so both will simultaneously
pass:
udev->head == udev->tail

Then the first thread goes to sleep and the second one pops the message
from the queue. Now assume udev->head == udev->tail. If the first thread
wakes up it will call wait_event_*() and sleep in the waitq. This
effectively turns the non-blocking FD into a blocking one.

We fix this by attempting to fetch events from the queue first and only
if we fail to retrieve any events we either return -EAGAIN (in case of
non-blocing read) or wait until there are more events.

This also fixes incorrect return code (we were returning 0 instead of
 -EAGAIN for non-blocking reads) when an event is "stolen" by another
thread. Blocking reads will now continue to wait instead of returning 0
in this scenario.

Count of 0 continues to be a special case, as per spec: we will check for
device existence and whether there are events in the queue, but no events
will be actually retrieved.

Reported-by: David Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
drivers/input/misc/uinput.c