From: Jonathan Cameron <jic23@kernel.org>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: linux-iio@vger.kernel.org
Subject: Re: [PATCH] iio:event: Fix and cleanup locking
Date: Tue, 18 Feb 2014 10:54:31 +0000 [thread overview]
Message-ID: <53033BE7.3040004@kernel.org> (raw)
In-Reply-To: <1392403786-22127-1-git-send-email-lars@metafoo.de>
On 14/02/14 18:49, Lars-Peter Clausen wrote:
> 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>
The patch looks fine. I'm a little worried that's too involved for this stage
in the merge cycle. So is this an issue observed in the wild (in which case
I probably want to get it upstream asap) or is it just a theoretical issue
at the moment? (e.g. can I leave it for the next merge window).
Actually without the spin lock in getfd, is there any path where it would allocate
two anon file descriptors?
Jonathan
> ---
> drivers/iio/industrialio-event.c | 83 ++++++++++++++++++++--------------------
> 1 file changed, 41 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/iio/industrialio-event.c b/drivers/iio/industrialio-event.c
> index c9c1419..0719443 100644
> --- a/drivers/iio/industrialio-event.c
> +++ b/drivers/iio/industrialio-event.c
> @@ -40,6 +40,7 @@ struct iio_event_interface {
> struct list_head dev_attr_list;
> unsigned long flags;
> struct attribute_group group;
> + struct mutex read_lock;
> };
>
> /**
> @@ -47,16 +48,17 @@ struct iio_event_interface {
> * @indio_dev: IIO device structure
> * @ev_code: What event
> * @timestamp: When the event occurred
> + *
> + * Note: The caller must make sure that this function is not running
> + * concurrently for the same indio_dev more than once.
> **/
> int iio_push_event(struct iio_dev *indio_dev, u64 ev_code, s64 timestamp)
> {
> struct iio_event_interface *ev_int = indio_dev->event_interface;
> struct iio_event_data ev;
> - unsigned long flags;
> int copied;
>
> /* Does anyone care? */
> - spin_lock_irqsave(&ev_int->wait.lock, flags);
> if (test_bit(IIO_BUSY_BIT_POS, &ev_int->flags)) {
>
> ev.id = ev_code;
> @@ -64,9 +66,8 @@ int iio_push_event(struct iio_dev *indio_dev, u64 ev_code, s64 timestamp)
>
> copied = kfifo_put(&ev_int->det_events, ev);
> if (copied != 0)
> - wake_up_locked_poll(&ev_int->wait, POLLIN);
> + wake_up_poll(&ev_int->wait, POLLIN);
> }
> - spin_unlock_irqrestore(&ev_int->wait.lock, flags);
>
> return 0;
> }
> @@ -87,10 +88,8 @@ static unsigned int iio_event_poll(struct file *filep,
>
> poll_wait(filep, &ev_int->wait, wait);
>
> - spin_lock_irq(&ev_int->wait.lock);
> if (!kfifo_is_empty(&ev_int->det_events))
> events = POLLIN | POLLRDNORM;
> - spin_unlock_irq(&ev_int->wait.lock);
>
> return events;
> }
> @@ -111,31 +110,40 @@ static ssize_t iio_event_chrdev_read(struct file *filep,
> if (count < sizeof(struct iio_event_data))
> return -EINVAL;
>
> - spin_lock_irq(&ev_int->wait.lock);
> - if (kfifo_is_empty(&ev_int->det_events)) {
> - if (filep->f_flags & O_NONBLOCK) {
> - ret = -EAGAIN;
> - goto error_unlock;
> - }
> - /* Blocking on device; waiting for something to be there */
> - ret = wait_event_interruptible_locked_irq(ev_int->wait,
> + do {
> + if (kfifo_is_empty(&ev_int->det_events)) {
> + if (filep->f_flags & O_NONBLOCK)
> + return -EAGAIN;
> +
> + ret = wait_event_interruptible(ev_int->wait,
> !kfifo_is_empty(&ev_int->det_events) ||
> indio_dev->info == NULL);
> - if (ret)
> - goto error_unlock;
> - if (indio_dev->info == NULL) {
> - ret = -ENODEV;
> - goto error_unlock;
> + if (ret)
> + return ret;
> + if (indio_dev->info == NULL)
> + return -ENODEV;
> }
> - /* Single access device so no one else can get the data */
> - }
>
> - ret = kfifo_to_user(&ev_int->det_events, buf, count, &copied);
> + if (mutex_lock_interruptible(&ev_int->read_lock))
> + return -ERESTARTSYS;
> + ret = kfifo_to_user(&ev_int->det_events, buf, count, &copied);
> + mutex_unlock(&ev_int->read_lock);
> +
> + if (ret)
> + return ret;
> +
> + /*
> + * If we couldn't read anything from the fifo (a different
> + * thread might have been faster) we either return -EAGAIN if
> + * the file descriptor is non-blocking, otherwise we go back to
> + * sleep and wait for more data to arrive.
> + */
> + if (copied == 0 && (filep->f_flags & O_NONBLOCK))
> + return -EAGAIN;
>
> -error_unlock:
> - spin_unlock_irq(&ev_int->wait.lock);
> + } while (copied == 0);
>
> - return ret ? ret : copied;
> + return copied;
> }
>
> static int iio_event_chrdev_release(struct inode *inode, struct file *filep)
> @@ -143,15 +151,7 @@ static int iio_event_chrdev_release(struct inode *inode, struct file *filep)
> struct iio_dev *indio_dev = filep->private_data;
> struct iio_event_interface *ev_int = indio_dev->event_interface;
>
> - spin_lock_irq(&ev_int->wait.lock);
> - __clear_bit(IIO_BUSY_BIT_POS, &ev_int->flags);
> - /*
> - * In order to maintain a clean state for reopening,
> - * clear out any awaiting events. The mask will prevent
> - * any new __iio_push_event calls running.
> - */
> - kfifo_reset_out(&ev_int->det_events);
> - spin_unlock_irq(&ev_int->wait.lock);
> + clear_bit(IIO_BUSY_BIT_POS, &ev_int->flags);
>
> iio_device_put(indio_dev);
>
> @@ -174,22 +174,20 @@ int iio_event_getfd(struct iio_dev *indio_dev)
> if (ev_int == NULL)
> return -ENODEV;
>
> - spin_lock_irq(&ev_int->wait.lock);
> - if (__test_and_set_bit(IIO_BUSY_BIT_POS, &ev_int->flags)) {
> - spin_unlock_irq(&ev_int->wait.lock);
> + if (test_and_set_bit(IIO_BUSY_BIT_POS, &ev_int->flags))
> return -EBUSY;
> - }
> - spin_unlock_irq(&ev_int->wait.lock);
> +
> iio_device_get(indio_dev);
>
> fd = anon_inode_getfd("iio:event", &iio_event_chrdev_fileops,
> indio_dev, O_RDONLY | O_CLOEXEC);
> if (fd < 0) {
> - spin_lock_irq(&ev_int->wait.lock);
> - __clear_bit(IIO_BUSY_BIT_POS, &ev_int->flags);
> - spin_unlock_irq(&ev_int->wait.lock);
> + clear_bit(IIO_BUSY_BIT_POS, &ev_int->flags);
> iio_device_put(indio_dev);
> + } else {
> + kfifo_reset_out(&ev_int->det_events);
> }
> +
> return fd;
> }
>
> @@ -425,6 +423,7 @@ static void iio_setup_ev_int(struct iio_event_interface *ev_int)
> {
> INIT_KFIFO(ev_int->det_events);
> init_waitqueue_head(&ev_int->wait);
> + mutex_init(&ev_int->read_lock);
> }
>
> static const char *iio_event_group_name = "events";
>
next prev parent reply other threads:[~2014-02-18 10:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-14 18:49 [PATCH] iio:event: Fix and cleanup locking Lars-Peter Clausen
2014-02-18 10:54 ` Jonathan Cameron [this message]
2014-02-18 11:37 ` Lars-Peter Clausen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53033BE7.3040004@kernel.org \
--to=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).