From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Yonghao Zhang <hyz3367@gmail.com>
Cc: andersson@kernel.org, linux-remoteproc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] remoteproc: core: Guard against a missing stop() in rproc_start()
Date: Fri, 16 Oct 2026 09:55:38 -0600 [thread overview]
Message-ID: <atJI-r0JBsnVfMVS@p14s> (raw)
In-Reply-To: <20260929075453.2324597-3-hyz3367@gmail.com>
On Tue, Sep 29, 2026 at 03:54:51PM +0800, Yonghao Zhang wrote:
> When the subdevice registration fails after a successful ops->start(),
> rproc_start() unrolls with an unconditional ops->stop() call: an
> implementation without stop() turns that error path into a NULL
> dereference, and there is no other way to undo a start once the
> processor is up.
>
> Nothing rules that implementation out. rproc_validate() checks the
> callbacks against the state a processor registers in: start() for
> an offline one, attach() for a detached one, which never look at
> stop(); the only written rule, Documentation/staging/remoteproc.rst
> ("Every remoteproc implementation should at least provide the ->start
> and ->stop handlers"), is a should the core does not enforce. The
> in-tree implementations all provide both, or neither when they only
> attach (commit 1168af40b1ad ("remoteproc: k3-r5: Add support for
> IPC-only mode for all R5Fs")), so none of them can reach the call
> today.
>
> Skip the rollback call when there is no stop(): with nothing to roll
> the start back with, the processor stays running and the failure is
> reported by the boot attempt itself.
>
> Fixes: 7bdc9650f036 ("remoteproc: Introduce subdevices")
> Signed-off-by: Yonghao Zhang <hyz3367@gmail.com>
> ---
> drivers/remoteproc/remoteproc_core.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 123aadb467a0..19e0ea3e7240 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1336,7 +1336,10 @@ static int rproc_start(struct rproc *rproc, const struct firmware *fw)
> return 0;
>
> stop_rproc:
> - rproc->ops->stop(rproc);
> + if (rproc->ops->stop)
> + rproc->ops->stop(rproc);
> + else
> + dev_err(dev, "can't roll %s back: no stop()\n", rproc->name);
I don't want to clutter the function's error path. Please move that to the
error path for rproc_start_subdevices() and call the correct "goto" based on the
validity of rproc->ops->stop.
> unprepare_subdevices:
> rproc_unprepare_subdevices(rproc);
> reset_table_ptr:
> --
> 2.34.1
>
next prev parent reply other threads:[~2026-10-16 15:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 7:54 [PATCH 0/4] remoteproc: core: Fix the error unwind paths Yonghao Zhang
2026-09-29 7:54 ` [PATCH 1/4] remoteproc: core: Reset freed vring entries to FW_RSC_ADDR_ANY Yonghao Zhang
2026-10-16 15:34 ` Mathieu Poirier
2026-09-29 7:54 ` [PATCH 2/4] remoteproc: core: Guard against a missing stop() in rproc_start() Yonghao Zhang
2026-10-16 15:55 ` Mathieu Poirier [this message]
2026-09-29 7:54 ` [PATCH 3/4] remoteproc: core: Roll a failed attach back with detach() when available Yonghao Zhang
2026-09-29 7:54 ` [PATCH 4/4] remoteproc: core: Clean up after a failed recovery Yonghao Zhang
2026-10-13 14:09 ` [PATCH 0/4] remoteproc: core: Fix the error unwind paths Yonghao Zhang
2026-10-13 15:18 ` 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=atJI-r0JBsnVfMVS@p14s \
--to=mathieu.poirier@linaro.org \
--cc=andersson@kernel.org \
--cc=hyz3367@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@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
all inboxes | Powered by JetHome®