All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ardelean, Alexandru" <alexandru.Ardelean@analog.com>
To: "jic23@kernel.org" <jic23@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	"lars@metafoo.de" <lars@metafoo.de>
Subject: Re: [RFC PATCH 07/14] iio: core: add simple centralized mechanism for ioctl() handlers
Date: Mon, 25 May 2020 07:24:51 +0000	[thread overview]
Message-ID: <3773c98d27b5043dae7d293bc4ab8268ae204c16.camel@analog.com> (raw)
In-Reply-To: <20200524174539.301026de@archlinux>

On Sun, 2020-05-24 at 17:45 +0100, Jonathan Cameron wrote:
> [External]
> 
> On Fri, 8 May 2020 16:53:41 +0300
> Alexandru Ardelean <alexandru.ardelean@analog.com> wrote:
> 
> > The aim of this is to reduce the organization violation of ioctl() calls in
> > IIO core. Currently, since the chardev is split across files, event ioctl()
> > calls need to be called in buffer ioctl() calls.
> > 
> > The 'industrialio-core.c' file will provide a 'iio_device_ioctl()' which
> > will iterate over a list of ioctls registered with the IIO device. These
> > can be event ioctl() or buffer ioctl() calls, or something else.
> > This is needed, since there is currently one chardev per IIO device and
> > that is used for both event handling and reading from the buffer.
> > 
> > Each ioctl() will have to return a IIO_IOCTL_UNHANDLED code (which is
> > positive 1), if the ioctl() did not handle the call in any. This eliminates
> > any potential ambiguities; if we were to have used error codes it would
> > have been uncertain whether they were actual errors, or whether
> > the registered ioctl() doesn't service the command.
> > 
> > If any ioctl() returns 0, it was considered that it was serviced
> > successfully and the loop will exit.
> > 
> > One assumption for all registered ioctl() handlers is that they are
> > statically allocated, so the iio_device_unregister() which just remove all
> > of them from the device's ioctl() handler list.
> > 
> > Also, something that is a bit hard to do [at this point] and may not be
> > worth the effort of doing, is to check whether registered ioctl()
> > calls/commands overlap. This should be unlikely to happen, and should get
> > caught at review time. Though, new ioctl() calls would likely not be added
> > too often.
> > 
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> 
> We seem to have dropped the locking in here.   What am I missing that
> stops us racing a remove with the ioctl?  If there is a reason that
> can't race, please add comments there so I don't wonders sometime in
> the future.
> 

Yeah.
My bad about the locking.
I have too many branches for this stuff.
But for the chardev split, there's a branch that should have the locking in
place.
I'll re-check that, when sending only the chardev split anyway.


> The check on iio_dev->info means we won't start the ioctl if the
> remove has been called, but if we switch immediately after that,
> anything can happen before we start calling the ioctls.
> 
> J
> 
> > ---
> >  drivers/iio/iio_core.h          | 14 ++++++++++++++
> >  drivers/iio/industrialio-core.c | 33 +++++++++++++++++++++++++++++++++
> >  include/linux/iio/iio.h         |  2 ++
> >  3 files changed, 49 insertions(+)
> > 
> > diff --git a/drivers/iio/iio_core.h b/drivers/iio/iio_core.h
> > index a527a66be9e5..34c3e19229d8 100644
> > --- a/drivers/iio/iio_core.h
> > +++ b/drivers/iio/iio_core.h
> > @@ -17,6 +17,20 @@ struct iio_dev;
> >  
> >  extern struct device_type iio_device_type;
> >  
> > +#define IIO_IOCTL_UNHANDLED	1
> > +struct iio_ioctl_handler {
> > +	struct list_head entry;
> > +	long (*ioctl)(struct iio_dev *indio_dev, struct file *filp,
> > +		      unsigned int cmd, unsigned long arg);
> > +};
> > +
> > +long iio_device_ioctl(struct iio_dev *indio_dev, struct file *filp,
> > +		      unsigned int cmd, unsigned long arg);
> > +
> > +void iio_device_ioctl_handler_register(struct iio_dev *indio_dev,
> > +				       struct iio_ioctl_handler *h);
> > +void iio_device_ioctl_handler_unregister(struct iio_ioctl_handler *h);
> > +
> >  int __iio_add_chan_devattr(const char *postfix,
> >  			   struct iio_chan_spec const *chan,
> >  			   ssize_t (*func)(struct device *dev,
> > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-
> > core.c
> > index 32e045c7f0c1..5df3af5e7dcb 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -1534,6 +1534,7 @@ struct iio_dev *iio_device_alloc(int sizeof_priv)
> >  	}
> >  	dev_set_name(&dev->dev, "iio:device%d", dev->id);
> >  	INIT_LIST_HEAD(&dev->buffer_list);
> > +	INIT_LIST_HEAD(&dev->ioctl_handlers);
> >  
> >  	return dev;
> >  }
> > @@ -1587,6 +1588,33 @@ struct iio_dev *devm_iio_device_alloc(struct device
> > *dev, int sizeof_priv)
> >  }
> >  EXPORT_SYMBOL_GPL(devm_iio_device_alloc);
> >  
> > +void iio_device_ioctl_handler_register(struct iio_dev *indio_dev,
> > +				       struct iio_ioctl_handler *h)
> > +{
> > +	/* this assumes that all ioctl() handlers are statically allocated */
> > +	list_add_tail(&h->entry, &indio_dev->ioctl_handlers);
> > +}
> > +
> > +long iio_device_ioctl(struct iio_dev *indio_dev, struct file *filp,
> > +		      unsigned int cmd, unsigned long arg)
> > +{
> > +	struct iio_ioctl_handler *h;
> > +	int ret;
> > +
> > +	if (!indio_dev->info)
> > +		return -ENODEV;
> 
> The locking is gone?  
> > +
> > +	list_for_each_entry(h, &indio_dev->ioctl_handlers, entry) {
> > +		ret = h->ioctl(indio_dev, filp, cmd, arg);
> > +		if (ret == 0)
> > +			return 0;
> > +		if (ret != IIO_IOCTL_UNHANDLED)
> > +			return ret;
> > +	}
> > +
> > +	return -EINVAL;
> > +}
> > +
> >  static int iio_check_unique_scan_index(struct iio_dev *indio_dev)
> >  {
> >  	int i, j;
> > @@ -1722,6 +1750,8 @@ EXPORT_SYMBOL(__iio_device_register);
> >   **/
> >  void iio_device_unregister(struct iio_dev *indio_dev)
> >  {
> > +	struct iio_ioctl_handler *h, *t;
> > +
> >  	cdev_device_del(indio_dev->chrdev, &indio_dev->dev);
> >  	iio_device_free_chrdev_id(&indio_dev->dev);
> >  
> > @@ -1731,6 +1761,9 @@ void iio_device_unregister(struct iio_dev *indio_dev)
> >  
> >  	iio_disable_all_buffers(indio_dev);
> >  
> > +	list_for_each_entry_safe(h, t, &indio_dev->ioctl_handlers, entry)
> > +		list_del(&h->entry);
> > +
> >  	indio_dev->info = NULL;
> >  
> >  	iio_device_wakeup_eventset(indio_dev);
> > diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
> > index 52992be44e9e..b6ca8d85629e 100644
> > --- a/include/linux/iio/iio.h
> > +++ b/include/linux/iio/iio.h
> > @@ -488,6 +488,7 @@ struct iio_buffer_setup_ops {
> >   * @currentmode:	[DRIVER] current operating mode
> >   * @dev:		[DRIVER] device structure, should be assigned a parent
> >   *			and owner
> > + * @ioctl_handlers:	[INTERN] list of registered ioctl handlers
> >   * @event_interface:	[INTERN] event chrdevs associated with interrupt
> > lines
> >   * @buffer:		[DRIVER] any buffer present
> >   * @buffer_list:	[INTERN] list of all buffers currently attached
> > @@ -529,6 +530,7 @@ struct iio_dev {
> >  	int				modes;
> >  	int				currentmode;
> >  	struct device			dev;
> > +	struct list_head		ioctl_handlers;
> >  
> >  	struct iio_event_interface	*event_interface;
> >  

  reply	other threads:[~2020-05-25  7:25 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-08 13:53 [RFC PATCH 00/14] iio: buffer: add support for multiple buffers Alexandru Ardelean
2020-05-08 13:53 ` [RFC PATCH 01/14] iio: Move scan mask management to the core Alexandru Ardelean
2020-05-08 13:53 ` [RFC PATCH 02/14] iio: hw_consumer: use new scanmask functions Alexandru Ardelean
2020-05-08 13:53 ` [RFC PATCH 03/14] iio: buffer: add back-ref from iio_buffer to iio_dev Alexandru Ardelean
2020-05-08 13:53 ` [RFC PATCH 04/14] iio: core,buffer: wrap iio_buffer_put() call into iio_buffers_put() Alexandru Ardelean
2020-05-08 13:53 ` [RFC PATCH 05/14] iio: core: register chardev only if needed Alexandru Ardelean
2020-05-24 16:40   ` Jonathan Cameron
2020-05-08 13:53 ` [RFC PATCH 06/14] iio: buffer,event: duplicate chardev creation for buffers & events Alexandru Ardelean
2020-05-08 13:53 ` [RFC PATCH 07/14] iio: core: add simple centralized mechanism for ioctl() handlers Alexandru Ardelean
2020-05-24 16:45   ` Jonathan Cameron
2020-05-25  7:24     ` Ardelean, Alexandru [this message]
2020-05-08 13:53 ` [RFC PATCH 08/14] iio: core: use new common ioctl() mechanism Alexandru Ardelean
2020-05-24 16:47   ` Jonathan Cameron
2020-05-25  7:27     ` Ardelean, Alexandru
2020-05-31 15:20       ` Jonathan Cameron
2020-05-08 13:53 ` [RFC PATCH 09/14] iio: buffer: split buffer sysfs creation to take buffer as primary arg Alexandru Ardelean
2020-05-24 16:49   ` Jonathan Cameron
2020-05-25  7:28     ` Ardelean, Alexandru
2020-05-31 15:21       ` Jonathan Cameron
2020-05-08 13:53 ` [RFC PATCH 10/14] iio: buffer: remove attrcount_orig var from sysfs creation Alexandru Ardelean
2020-05-08 13:53 ` [RFC PATCH 11/14] iio: buffer: add underlying device object and convert buffers to devices Alexandru Ardelean
2020-05-08 13:53 ` [RFC PATCH 12/14] iio: buffer: symlink the scan_elements dir back into IIO device's dir Alexandru Ardelean
2020-05-08 13:53 ` [RFC PATCH 13/14] iio: unpack all iio buffer attributes correctly Alexandru Ardelean
2020-05-24 17:28   ` Jonathan Cameron
2020-05-08 13:53 ` [RFC PATCH 14/14] iio: buffer: convert single buffer to list of buffers Alexandru Ardelean
2020-05-09  8:52 ` [RFC PATCH 00/14] iio: buffer: add support for multiple buffers Lars-Peter Clausen
2020-05-10 10:09   ` Jonathan Cameron
2020-05-11 10:33     ` Ardelean, Alexandru
2020-05-11 10:37       ` Lars-Peter Clausen
2020-05-11 13:03         ` Ardelean, Alexandru
2020-05-11 13:24           ` Ardelean, Alexandru
2020-05-11 13:58             ` Lars-Peter Clausen
2020-05-11 14:56               ` Ardelean, Alexandru
2020-05-11 19:56                 ` Lars-Peter Clausen
2020-05-12  6:26                   ` Ardelean, Alexandru
2020-05-16 13:08                     ` Ardelean, Alexandru
2020-05-16 16:24                       ` Jonathan Cameron
2020-05-17  6:26                         ` Ardelean, Alexandru
2020-05-17 13:40                           ` Jonathan Cameron

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=3773c98d27b5043dae7d293bc4ab8268ae204c16.camel@analog.com \
    --to=alexandru.ardelean@analog.com \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.