tree 9dd4d0974af521bdc8a6f727526b2e30b8fcc53a
parent 931878405b869093c90d57a0a34f0c2b3641c4ea
author Lars-Peter Clausen <lars@metafoo.de> 1392403740 +0000
committer Jonathan Cameron <jic23@kernel.org> 1393170805 +0000

iio:event: Fix and cleanup locking

The event code currently holds a spinlock with IRQs disabled while calling
kfifo_to_user(). kfifo_to_user() can generate a page fault though, which means
we have to be able to sleep, which is not possible if the interrupts are
disabled. The good thing is that kfifo handles concurrent read and write access
just fine as long as there is only one reader and one writer, so we do not any
locking to protect against concurrent access from the read and writer thread. It
is possible though that userspace is trying to read from the event FIFO from
multiple concurrent threads, so we need to add locking to protect against this.
This is done using a mutex. The mutex will only protect the kfifo_to_user()
call, it will not protect the waitqueue. This means that multiple threads can be
waiting for new data and once a new event is added to the FIFO all waiting
threads will be woken up. If one of those threads is unable to read any data
(because another thread already read all the data) it will go back to sleep. The
only remaining issue is that now that the clearing of the BUSY flag and the
emptying of the FIFO does no longer happen in one atomic step it is possible
that a event is added to the FIFO after it has been emptied and this sample will
be visible the next time a new event file descriptor is created. To avoid this
rather move the emptying of the FIFO from iio_event_chrdev_release to
iio_event_getfd().

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>