From: Nathan_Lynch@mentor.com (Nathan Lynch)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 4/4] remoteproc: debugfs: Add ability to boot remote processor using debugfs
Date: Fri, 28 Aug 2015 10:23:14 -0500 [thread overview]
Message-ID: <55E07CE2.2050704@mentor.com> (raw)
In-Reply-To: <1440757911-9120-5-git-send-email-lee.jones@linaro.org>
On 08/28/2015 05:31 AM, Lee Jones wrote:
> +static ssize_t rproc_state_write(struct file *filp, const char __user *userbuf,
> + size_t count, loff_t *ppos)
> +{
> + struct rproc *rproc = filp->private_data;
> + char buf[2];
> + int ret;
> +
> + ret = copy_from_user(buf, userbuf, 1);
> + if (ret)
> + return -EFAULT;
> +
> + switch (buf[0]) {
> + case '0':
> + rproc_shutdown(rproc);
> + break;
> + case '1':
> + ret = rproc_boot(rproc);
> + if (ret)
> + dev_warn(&rproc->dev, "Boot failed: %d\n", ret);
> + break;
> + default:
> + dev_err(&rproc->dev, "Unrecognised option: %x\n", buf[1]);
> + return -EINVAL;
This prints uninitialized kernel stack contents instead of what was
copied from user space.
Is the dev_err statement really necessary anyway?
> + }
> +
> + return count;
> +}
If rproc_boot fails, that should be reflected in the syscall result.
This interface is essentially exposing the remoteproc->power refcount to
user space; is that okay? Seems like it makes it easy to underflow
remoteproc->power through successive shutdown calls.
The other debugfs interface in remoteproc that has a write method
(recovery) accepts more expressive string commands as opposed to 0/1.
It would be more consistent for this interface to take commands such as
"boot" and "shutdown" IMO.
WARNING: multiple messages have this Message-ID (diff)
From: Nathan Lynch <Nathan_Lynch@mentor.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: ohad@wizery.com, devicetree@vger.kernel.org, kernel@stlinux.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Ludovic Barre <ludovic.barre@st.com>
Subject: Re: [PATCH v2 4/4] remoteproc: debugfs: Add ability to boot remote processor using debugfs
Date: Fri, 28 Aug 2015 10:23:14 -0500 [thread overview]
Message-ID: <55E07CE2.2050704@mentor.com> (raw)
In-Reply-To: <1440757911-9120-5-git-send-email-lee.jones@linaro.org>
On 08/28/2015 05:31 AM, Lee Jones wrote:
> +static ssize_t rproc_state_write(struct file *filp, const char __user *userbuf,
> + size_t count, loff_t *ppos)
> +{
> + struct rproc *rproc = filp->private_data;
> + char buf[2];
> + int ret;
> +
> + ret = copy_from_user(buf, userbuf, 1);
> + if (ret)
> + return -EFAULT;
> +
> + switch (buf[0]) {
> + case '0':
> + rproc_shutdown(rproc);
> + break;
> + case '1':
> + ret = rproc_boot(rproc);
> + if (ret)
> + dev_warn(&rproc->dev, "Boot failed: %d\n", ret);
> + break;
> + default:
> + dev_err(&rproc->dev, "Unrecognised option: %x\n", buf[1]);
> + return -EINVAL;
This prints uninitialized kernel stack contents instead of what was
copied from user space.
Is the dev_err statement really necessary anyway?
> + }
> +
> + return count;
> +}
If rproc_boot fails, that should be reflected in the syscall result.
This interface is essentially exposing the remoteproc->power refcount to
user space; is that okay? Seems like it makes it easy to underflow
remoteproc->power through successive shutdown calls.
The other debugfs interface in remoteproc that has a write method
(recovery) accepts more expressive string commands as opposed to 0/1.
It would be more consistent for this interface to take commands such as
"boot" and "shutdown" IMO.
WARNING: multiple messages have this Message-ID (diff)
From: Nathan Lynch <Nathan_Lynch@mentor.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: <linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <kernel@stlinux.com>,
<ohad@wizery.com>, <devicetree@vger.kernel.org>,
Ludovic Barre <ludovic.barre@st.com>
Subject: Re: [PATCH v2 4/4] remoteproc: debugfs: Add ability to boot remote processor using debugfs
Date: Fri, 28 Aug 2015 10:23:14 -0500 [thread overview]
Message-ID: <55E07CE2.2050704@mentor.com> (raw)
In-Reply-To: <1440757911-9120-5-git-send-email-lee.jones@linaro.org>
On 08/28/2015 05:31 AM, Lee Jones wrote:
> +static ssize_t rproc_state_write(struct file *filp, const char __user *userbuf,
> + size_t count, loff_t *ppos)
> +{
> + struct rproc *rproc = filp->private_data;
> + char buf[2];
> + int ret;
> +
> + ret = copy_from_user(buf, userbuf, 1);
> + if (ret)
> + return -EFAULT;
> +
> + switch (buf[0]) {
> + case '0':
> + rproc_shutdown(rproc);
> + break;
> + case '1':
> + ret = rproc_boot(rproc);
> + if (ret)
> + dev_warn(&rproc->dev, "Boot failed: %d\n", ret);
> + break;
> + default:
> + dev_err(&rproc->dev, "Unrecognised option: %x\n", buf[1]);
> + return -EINVAL;
This prints uninitialized kernel stack contents instead of what was
copied from user space.
Is the dev_err statement really necessary anyway?
> + }
> +
> + return count;
> +}
If rproc_boot fails, that should be reflected in the syscall result.
This interface is essentially exposing the remoteproc->power refcount to
user space; is that okay? Seems like it makes it easy to underflow
remoteproc->power through successive shutdown calls.
The other debugfs interface in remoteproc that has a write method
(recovery) accepts more expressive string commands as opposed to 0/1.
It would be more consistent for this interface to take commands such as
"boot" and "shutdown" IMO.
next prev parent reply other threads:[~2015-08-28 15:23 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-28 10:31 [PATCH v2 0/4] remoteproc: Add driver for STMicroelectronics platforms Lee Jones
2015-08-28 10:31 ` Lee Jones
2015-08-28 10:31 ` [PATCH v2 1/4] ARM: STiH407: Add nodes for RemoteProc Lee Jones
2015-08-28 10:31 ` Lee Jones
2015-09-01 8:28 ` [STLinux Kernel] " Peter Griffin
2015-09-01 8:28 ` Peter Griffin
2015-09-01 8:28 ` Peter Griffin
2015-09-01 9:11 ` Lee Jones
2015-09-01 9:11 ` Lee Jones
2015-09-01 9:11 ` Lee Jones
2015-09-01 9:17 ` Peter Griffin
2015-09-01 9:17 ` Peter Griffin
2015-09-01 9:17 ` Peter Griffin
2015-08-28 10:31 ` [PATCH v2 2/4] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver Lee Jones
2015-08-28 10:31 ` Lee Jones
2015-08-31 15:28 ` Rob Herring
2015-08-31 15:28 ` Rob Herring
2015-08-31 15:28 ` Rob Herring
2015-09-01 10:41 ` Lee Jones
2015-09-01 10:41 ` Lee Jones
2015-09-01 11:49 ` Rob Herring
2015-09-01 11:49 ` Rob Herring
2015-09-01 11:49 ` Rob Herring
2015-09-01 8:58 ` [STLinux Kernel] " Peter Griffin
2015-09-01 8:58 ` Peter Griffin
2015-09-01 9:14 ` Lee Jones
2015-09-01 9:14 ` Lee Jones
2015-09-01 9:14 ` Lee Jones
2015-09-01 12:54 ` Lee Jones
2015-09-01 12:54 ` Lee Jones
2015-08-28 10:31 ` [PATCH v2 3/4] remoteproc: Supply controller driver for ST's Remote Processors Lee Jones
2015-08-28 10:31 ` Lee Jones
2015-08-28 16:24 ` Nathan Lynch
2015-08-28 16:24 ` Nathan Lynch
2015-08-28 16:24 ` Nathan Lynch
2015-09-01 7:55 ` Lee Jones
2015-09-01 7:55 ` Lee Jones
2015-09-01 7:55 ` Lee Jones
2015-09-01 8:17 ` [STLinux Kernel] " Peter Griffin
2015-09-01 8:17 ` Peter Griffin
2015-09-01 9:12 ` Lee Jones
2015-09-01 9:12 ` Lee Jones
2015-09-01 9:12 ` Lee Jones
2015-08-28 10:31 ` [PATCH v2 4/4] remoteproc: debugfs: Add ability to boot remote processor using debugfs Lee Jones
2015-08-28 10:31 ` Lee Jones
2015-08-28 15:23 ` Nathan Lynch [this message]
2015-08-28 15:23 ` Nathan Lynch
2015-08-28 15:23 ` Nathan Lynch
2015-09-01 7:48 ` Lee Jones
2015-09-01 7:48 ` Lee Jones
2015-08-28 17:17 ` Florian Fainelli
2015-08-28 17:17 ` Florian Fainelli
2015-08-28 17:17 ` Florian Fainelli
2015-09-01 7:41 ` Lee Jones
2015-09-01 7:41 ` Lee Jones
2015-09-01 7:41 ` Lee Jones
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=55E07CE2.2050704@mentor.com \
--to=nathan_lynch@mentor.com \
--cc=linux-arm-kernel@lists.infradead.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.