+41
−42
Loading
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: