From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Loic Pallardy <loic.pallardy@st.com>
Cc: ohad@wizery.com, mathieu.poirier@linaro.org,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
arnaud.pouliquen@st.com, benjamin.gaignard@linaro.org,
fabien.dessenne@st.com, s-anna@ti.com
Subject: Re: [RFC 1/2] remoteproc: sysfs: authorize rproc shutdown when rproc is crashed
Date: Wed, 11 Mar 2020 16:27:10 -0700 [thread overview]
Message-ID: <20200311232707.GA1214176@minitux> (raw)
In-Reply-To: <1583924072-20648-2-git-send-email-loic.pallardy@st.com>
On Wed 11 Mar 03:54 PDT 2020, Loic Pallardy wrote:
> When remoteproc recovery is disabled and rproc crashed, user space
> client has no way to reboot co-processor except by a complete platform
> reboot.
> Indeed rproc_shutdown() is called by sysfs state_store() only is rproc
> state is RPROC_RUNNING.
>
> This patch offers the possibility to shutdown the co-processor if
> it is in RPROC_CRASHED state and so to restart properly co-processor
> from sysfs interface.
>
I did recently run into a similar problem when I fed my remoteproc
faulty firmware, which lead to it recovering immediately upon boot. The
amount of time spent in !CRASHED state was minimal, so I didn't have any
way to stop the remoteproc.
> Signed-off-by: Loic Pallardy <loic.pallardy@st.com>
> ---
> drivers/remoteproc/remoteproc_core.c | 2 +-
> drivers/remoteproc/remoteproc_sysfs.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 097f33e4f1f3..7ac87a75cd1b 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1812,7 +1812,7 @@ void rproc_shutdown(struct rproc *rproc)
> if (!atomic_dec_and_test(&rproc->power))
> goto out;
>
> - ret = rproc_stop(rproc, false);
> + ret = rproc_stop(rproc, rproc->state == RPROC_CRASHED);
Afaict this is unrelated to the problem you're describing in the commit
message.
> if (ret) {
> atomic_inc(&rproc->power);
> goto out;
> diff --git a/drivers/remoteproc/remoteproc_sysfs.c b/drivers/remoteproc/remoteproc_sysfs.c
> index 7f8536b73295..1029458a4678 100644
> --- a/drivers/remoteproc/remoteproc_sysfs.c
> +++ b/drivers/remoteproc/remoteproc_sysfs.c
> @@ -101,7 +101,7 @@ static ssize_t state_store(struct device *dev,
> if (ret)
> dev_err(&rproc->dev, "Boot failed: %d\n", ret);
> } else if (sysfs_streq(buf, "stop")) {
> - if (rproc->state != RPROC_RUNNING)
> + if (rproc->state != RPROC_RUNNING && rproc->state != RPROC_CRASHED)
Analogous to the problem reported by Alex here
https://patchwork.kernel.org/patch/11413161/ the handling of stop seems
racy.
In particular, I believe you're failing to protect against a race
with a just scheduled rproc_crash_handler_work() being executed after
the mutex_unlock() in rproc_shutdown()...
With Alex fix that should be less of a problem though...
Regards,
Bjorn
> return -EINVAL;
>
> rproc_shutdown(rproc);
> --
> 2.7.4
>
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Loic Pallardy <loic.pallardy@st.com>
Cc: ohad@wizery.com, mathieu.poirier@linaro.org,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
arnaud.pouliquen@st.com, benjamin.gaignard@linaro.org,
fabien.dessenne@st.com, s-anna@ti.com
Subject: Re: [RFC 1/2] remoteproc: sysfs: authorize rproc shutdown when rproc is crashed
Date: Wed, 11 Mar 2020 16:27:07 -0700 [thread overview]
Message-ID: <20200311232707.GA1214176@minitux> (raw)
In-Reply-To: <1583924072-20648-2-git-send-email-loic.pallardy@st.com>
On Wed 11 Mar 03:54 PDT 2020, Loic Pallardy wrote:
> When remoteproc recovery is disabled and rproc crashed, user space
> client has no way to reboot co-processor except by a complete platform
> reboot.
> Indeed rproc_shutdown() is called by sysfs state_store() only is rproc
> state is RPROC_RUNNING.
>
> This patch offers the possibility to shutdown the co-processor if
> it is in RPROC_CRASHED state and so to restart properly co-processor
> from sysfs interface.
>
I did recently run into a similar problem when I fed my remoteproc
faulty firmware, which lead to it recovering immediately upon boot. The
amount of time spent in !CRASHED state was minimal, so I didn't have any
way to stop the remoteproc.
> Signed-off-by: Loic Pallardy <loic.pallardy@st.com>
> ---
> drivers/remoteproc/remoteproc_core.c | 2 +-
> drivers/remoteproc/remoteproc_sysfs.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 097f33e4f1f3..7ac87a75cd1b 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1812,7 +1812,7 @@ void rproc_shutdown(struct rproc *rproc)
> if (!atomic_dec_and_test(&rproc->power))
> goto out;
>
> - ret = rproc_stop(rproc, false);
> + ret = rproc_stop(rproc, rproc->state == RPROC_CRASHED);
Afaict this is unrelated to the problem you're describing in the commit
message.
> if (ret) {
> atomic_inc(&rproc->power);
> goto out;
> diff --git a/drivers/remoteproc/remoteproc_sysfs.c b/drivers/remoteproc/remoteproc_sysfs.c
> index 7f8536b73295..1029458a4678 100644
> --- a/drivers/remoteproc/remoteproc_sysfs.c
> +++ b/drivers/remoteproc/remoteproc_sysfs.c
> @@ -101,7 +101,7 @@ static ssize_t state_store(struct device *dev,
> if (ret)
> dev_err(&rproc->dev, "Boot failed: %d\n", ret);
> } else if (sysfs_streq(buf, "stop")) {
> - if (rproc->state != RPROC_RUNNING)
> + if (rproc->state != RPROC_RUNNING && rproc->state != RPROC_CRASHED)
Analogous to the problem reported by Alex here
https://patchwork.kernel.org/patch/11413161/ the handling of stop seems
racy.
In particular, I believe you're failing to protect against a race
with a just scheduled rproc_crash_handler_work() being executed after
the mutex_unlock() in rproc_shutdown()...
With Alex fix that should be less of a problem though...
Regards,
Bjorn
> return -EINVAL;
>
> rproc_shutdown(rproc);
> --
> 2.7.4
>
next prev parent reply other threads:[~2020-03-11 23:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-11 10:54 [RFC 0/2] Allow client to recover crashed processor Loic Pallardy
2020-03-11 10:54 ` Loic Pallardy
2020-03-11 10:54 ` [RFC 1/2] remoteproc: sysfs: authorize rproc shutdown when rproc is crashed Loic Pallardy
2020-03-11 10:54 ` Loic Pallardy
2020-03-11 21:45 ` Mathieu Poirier
2020-03-12 8:00 ` Loic PALLARDY
2020-03-11 23:27 ` Bjorn Andersson [this message]
2020-03-11 23:27 ` Bjorn Andersson
2020-03-12 8:12 ` Loic PALLARDY
2020-03-25 17:57 ` Mathieu Poirier
2020-03-25 18:30 ` Loic PALLARDY
2020-03-25 21:42 ` Mathieu Poirier
2020-03-11 10:54 ` [RFC 2/2] remoteproc: core: keep rproc in crash state in case of recovery failure Loic Pallardy
2020-03-11 10:54 ` Loic Pallardy
2020-05-06 2:05 ` Bjorn Andersson
2020-03-11 14:56 ` [RFC 0/2] Allow client to recover crashed processor Mathieu Poirier
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=20200311232707.GA1214176@minitux \
--to=bjorn.andersson@linaro.org \
--cc=arnaud.pouliquen@st.com \
--cc=benjamin.gaignard@linaro.org \
--cc=fabien.dessenne@st.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=loic.pallardy@st.com \
--cc=mathieu.poirier@linaro.org \
--cc=ohad@wizery.com \
--cc=s-anna@ti.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.