All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Ohad Ben-Cohen <ohad@wizery.com>,
	linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH v2 1/1] rpmsg: ctrl: Introduce new RPMSG_CREATE/RELEASE_DEV_IOCTL controls
Date: Tue, 22 Jun 2021 13:56:22 -0600	[thread overview]
Message-ID: <20210622195622.GA1006507@p14s> (raw)
In-Reply-To: <343c372e-0c0a-ad4e-356b-47eb975ce0e0@foss.st.com>

On Tue, Jun 22, 2021 at 09:43:49AM +0200, Arnaud POULIQUEN wrote:
> Hi Mathieu
> 
> On 6/22/21 1:16 AM, Mathieu Poirier wrote:
> > On Mon, Jun 21, 2021 at 02:58:00PM +0200, Arnaud Pouliquen wrote:
> >> Allow the user space application to create and release an rpmsg device
> >> by adding RPMSG_CREATE_DEV_IOCTL and RPMSG_RELEASE_DEV_IOCTL ioctrls to
> >> the /dev/rpmsg_ctrl interface
> >>
> >> The RPMSG_CREATE_DEV_IOCTL Ioctl can be used to instantiate a local rpmsg
> >> device.
> >> Depending on the back-end implementation, the associated rpmsg driver is
> >> probed and a NS announcement can be sent to the remote processor.
> >>
> >> The RPMSG_RELEASE_DEV_IOCTL allows the user application to release a
> >> rpmsg device created either by the remote processor or with the
> >> RPMSG_CREATE_DEV_IOCTL call.
> >> Depending on the back-end implementation, the associated rpmsg driver is
> >> removed and a NS destroy rpmsg can be sent to the remote processor.
> >>
> >> Suggested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> >> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> >> ---
> >>  drivers/rpmsg/rpmsg_ctrl.c | 37 +++++++++++++++++++++++++++++++++----
> >>  include/uapi/linux/rpmsg.h | 10 ++++++++++
> >>  2 files changed, 43 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/rpmsg/rpmsg_ctrl.c b/drivers/rpmsg/rpmsg_ctrl.c
> >> index eeb1708548c1..cb19e32d05e1 100644
> >> --- a/drivers/rpmsg/rpmsg_ctrl.c
> >> +++ b/drivers/rpmsg/rpmsg_ctrl.c
> >> @@ -23,6 +23,7 @@
> >>  #include <uapi/linux/rpmsg.h>
> >>  
> >>  #include "rpmsg_char.h"
> >> +#include "rpmsg_internal.h"
> >>  
> >>  static dev_t rpmsg_major;
> >>  
> >> @@ -37,11 +38,13 @@ static DEFINE_IDA(rpmsg_minor_ida);
> >>   * @rpdev:	underlaying rpmsg device
> >>   * @cdev:	cdev for the ctrl device
> >>   * @dev:	device for the ctrl device
> >> + * @ctrl_lock:	serialize the ioctrls.
> >>   */
> >>  struct rpmsg_ctrldev {
> >>  	struct rpmsg_device *rpdev;
> >>  	struct cdev cdev;
> >>  	struct device dev;
> >> +	struct mutex ctrl_lock;
> >>  };
> >>  
> >>  static int rpmsg_ctrldev_open(struct inode *inode, struct file *filp)
> >> @@ -70,9 +73,8 @@ static long rpmsg_ctrldev_ioctl(struct file *fp, unsigned int cmd,
> >>  	void __user *argp = (void __user *)arg;
> >>  	struct rpmsg_endpoint_info eptinfo;
> >>  	struct rpmsg_channel_info chinfo;
> >> -
> >> -	if (cmd != RPMSG_CREATE_EPT_IOCTL)
> >> -		return -EINVAL;
> >> +	struct rpmsg_device *rpdev;
> >> +	int ret = 0;
> >>  
> >>  	if (copy_from_user(&eptinfo, argp, sizeof(eptinfo)))
> >>  		return -EFAULT;
> >> @@ -82,7 +84,33 @@ static long rpmsg_ctrldev_ioctl(struct file *fp, unsigned int cmd,
> >>  	chinfo.src = eptinfo.src;
> >>  	chinfo.dst = eptinfo.dst;
> >>  
> >> -	return rpmsg_chrdev_eptdev_create(ctrldev->rpdev, &ctrldev->dev, chinfo);
> >> +	mutex_lock(&ctrldev->ctrl_lock);
> > 
> > Have you been able to verify the VFS layer doesn't take care of serializing
> > ioctl() and file accesses in general?  I did a quick search in the drivers/
> > directory and the vast majority of implementations don't use a lock.
> 
> Please find my answer here https://lkml.org/lkml/2021/6/21/235

Ah ok, I hadn't noticed that one.

> I tested by suppressing the lock and adding msleep to check a potential atomic.
> in the rpmsg_ctrldev_ioctl function. Nothing seems prevent the re-entrance.

Thanks for testing this out.  I did some research on my side and turns out
unlocked_ioctl() was introduced to get rid of the Big Kernel Lock rather than
indicate that serialisation is not supported by this interface.  Someone also
asked the exact same question here [1].

So yes, locking is required. 

Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>

[1]. https://stackoverflow.com/questions/18874962/linux-device-driver-file-operations-it-is-possible-to-have-race-conditions

> 
> Regards,
> Arnaud
> 
> > 
> > Thanks,
> > Mathieu
> > 
> >> +	switch (cmd) {
> >> +	case RPMSG_CREATE_EPT_IOCTL:
> >> +		ret = rpmsg_chrdev_eptdev_create(ctrldev->rpdev, &ctrldev->dev, chinfo);
> >> +		break;
> >> +
> >> +	case RPMSG_CREATE_DEV_IOCTL:
> >> +		rpdev = rpmsg_create_channel(ctrldev->rpdev, &chinfo);
> >> +		if (!rpdev) {
> >> +			dev_err(&ctrldev->dev, "failed to create %s channel\n", chinfo.name);
> >> +			ret = -ENXIO;
> >> +		}
> >> +		break;
> >> +
> >> +	case RPMSG_RELEASE_DEV_IOCTL:
> >> +		ret = rpmsg_release_channel(ctrldev->rpdev, &chinfo);
> >> +		if (ret)
> >> +			dev_err(&ctrldev->dev, "failed to release %s channel (%d)\n",
> >> +				chinfo.name, ret);
> >> +		break;
> >> +
> >> +	default:
> >> +		ret = -EINVAL;
> >> +	}
> >> +	mutex_unlock(&ctrldev->ctrl_lock);
> >> +
> >> +	return ret;
> >>  };
> >>  
> >>  static const struct file_operations rpmsg_ctrldev_fops = {
> >> @@ -119,6 +147,7 @@ static int rpmsg_ctrldev_probe(struct rpmsg_device *rpdev)
> >>  	device_initialize(dev);
> >>  	dev->parent = &rpdev->dev;
> >>  
> >> +	mutex_init(&ctrldev->ctrl_lock);
> >>  	cdev_init(&ctrldev->cdev, &rpmsg_ctrldev_fops);
> >>  	ctrldev->cdev.owner = THIS_MODULE;
> >>  
> >> diff --git a/include/uapi/linux/rpmsg.h b/include/uapi/linux/rpmsg.h
> >> index f5ca8740f3fb..1637e68177d9 100644
> >> --- a/include/uapi/linux/rpmsg.h
> >> +++ b/include/uapi/linux/rpmsg.h
> >> @@ -33,4 +33,14 @@ struct rpmsg_endpoint_info {
> >>   */
> >>  #define RPMSG_DESTROY_EPT_IOCTL	_IO(0xb5, 0x2)
> >>  
> >> +/**
> >> + * Instantiate a new local rpmsg service device.
> >> + */
> >> +#define RPMSG_CREATE_DEV_IOCTL	_IOW(0xb5, 0x3, struct rpmsg_endpoint_info)
> >> +
> >> +/**
> >> + * Release a local rpmsg device.
> >> + */
> >> +#define RPMSG_RELEASE_DEV_IOCTL	_IOW(0xb5, 0x4, struct rpmsg_endpoint_info)
> >> +
> >>  #endif
> >> -- 
> >> 2.17.1
> >>

      reply	other threads:[~2021-06-22 19:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-21 12:57 [PATCH v2 0/1] rpmsg: ctrl: Add ability to instantiate rpmsg device locally Arnaud Pouliquen
2021-06-21 12:58 ` [PATCH v2 1/1] rpmsg: ctrl: Introduce new RPMSG_CREATE/RELEASE_DEV_IOCTL controls Arnaud Pouliquen
2021-06-21 23:16   ` Mathieu Poirier
2021-06-22  7:43     ` Arnaud POULIQUEN
2021-06-22 19:56       ` Mathieu Poirier [this message]

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=20210622195622.GA1006507@p14s \
    --to=mathieu.poirier@linaro.org \
    --cc=arnaud.pouliquen@foss.st.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=ohad@wizery.com \
    /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.