1. 23 Feb, 2014 1 commit
    • Lars-Peter Clausen's avatar
      iio:event: Fix and cleanup locking · b91accaf
      Lars-Peter Clausen authored
      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: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      b91accaf
  2. 22 Feb, 2014 3 commits
  3. 18 Feb, 2014 6 commits
  4. 15 Feb, 2014 8 commits
  5. 14 Feb, 2014 22 commits