| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAPDyKFpjP07826FXh8XveXiH7ta+N=upYaowf7r6gyNWPSFfqA@mail.gmail.com>
Date: Thu, 25 Sep 2025 12:18:39 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Peng Fan <peng.fan@....com>
Cc: Bjorn Andersson <andersson@...nel.org>, Mathieu Poirier <mathieu.poirier@...aro.org>,
Shawn Guo <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>, Fabio Estevam <festevam@...il.com>,
Hiago De Franco <hiago.franco@...adex.com>, linux-remoteproc@...r.kernel.org,
imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, Frank Li <Frank.Li@....com>,
Daniel Baluta <daniel.baluta@....com>
Subject: Re: [PATCH v2 1/6] remoteproc: imx_rproc: Fix runtime PM cleanup
order and error handling
On Tue, 23 Sept 2025 at 07:17, Peng Fan <peng.fan@....com> wrote:
>
> The order of runtime PM API calls in the remove path is wrong.
> pm_runtime_put() should be called before pm_runtime_disable(), per the
> runtime PM guidelines. Calling pm_runtime_disable() prematurely can
> lead to incorrect reference counting and improper device suspend behavior.
This isn't entirely correct as it depends a bit more on the runtime PM
deployment.
More importantly, even if you would call pm_runtime_put() before the
call to pm_runtime_disable() doesn't necessarily mean that the device
becomes runtime suspended, as it can be prevented by user-space for
example, assuming that is the goal.
To make sure the device is put back into a low power-state, this is
the typical pattern that is deployed in a driver's ->remove()
callback.
*) Call pm_runtime_get_sync(), to make sure the device gets the runtime resumed.
Not needed in this case, as the runtime PM usage count was increased
during ->probe() and not dropped).
*) Turn off resources that correspond to what the runtime PM callbacks
in the driver are managing.
Not needed, as there are no runtime PM callbacks for the driver.
*) Call pm_runtime_disable() and then pm_runtime_put_noidle(). This
makes sure that when ->remove() is completed, the device is in a low
power-state and the runtime PM usage count has been restored.
*) If there are PM domains, those are turned off by calling
dev_pm_domain_detach_list(), or from the driver core (after the
->remove() callback has been completed) for the single PM domain case.
That said, one could consider converting the pm_runtime_put() here
into a pm_runtime_put_noidle(), to make it clear that this is only
about restoring the usage count, but I don't think it's a big deal.
>
> Additionally, proper cleanup should be done when rproc_add() fails by
> invoking both pm_runtime_put() and pm_runtime_disable() to avoid leaving
> the device in an inconsistent power state.
Right, this deserved to be fixed.
>
> With using devm_pm_runtime_enable() for automatic resource management and
> introducing a devres-managed cleanup action imx_rproc_pm_runtime_put() to
> enforce correct PM API usage and simplify error paths, the upper two
> issues could be fixed. Also print out error log in case of error.
I really don't want to encourage people to use
devm_pm_runtime_enable(), simply because it's not always a good fit
when making sure things get turned off in the correct sequence. In
particular, as it's just about saving one/two lines of code, this
doesn't make sense to me.
I suggest you follow the similar pattern as I explained above for
->remove(), for the error path in ->probe() too. So, calling
pm_runtime_disable() and pm_runtime_put_noidle() should do the trick
for this too, I think.
>
> Fixes: a876a3aacc43 ("remoteproc: imx_rproc: detect and attach to pre-booted remote cores")
> Cc: Ulf Hansson <ulf.hansson@...aro.org>
> Cc: Hiago De Franco <hiago.franco@...adex.com>
> Reviewed-by: Frank Li <Frank.Li@....com>
> Reviewed-by: Daniel Baluta <daniel.baluta@....com>
> Signed-off-by: Peng Fan <peng.fan@....com>
Kind regards
Uffe
> ---
> drivers/remoteproc/imx_rproc.c | 24 +++++++++++++++++++-----
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index bb25221a4a8987ff427d68e2a5535f0e156b0097..12305f36552fb5265b0953a099ea0d561880e3ff 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -1046,6 +1046,13 @@ static int imx_rproc_sys_off_handler(struct sys_off_data *data)
> return NOTIFY_DONE;
> }
>
> +static void imx_rproc_pm_runtime_put(void *data)
> +{
> + struct device *dev = data;
> +
> + pm_runtime_put(dev);
> +}
> +
> static int imx_rproc_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -1125,12 +1132,23 @@ static int imx_rproc_probe(struct platform_device *pdev)
> }
>
> if (dcfg->method == IMX_RPROC_SCU_API) {
> - pm_runtime_enable(dev);
> + ret = devm_pm_runtime_enable(dev);
> + if (ret) {
> + dev_err(dev, "Failed to enable runtime PM, %d\n", ret);
> + goto err_put_clk;
> + }
> +
> ret = pm_runtime_resume_and_get(dev);
> if (ret) {
> dev_err(dev, "pm_runtime get failed: %d\n", ret);
> goto err_put_clk;
> }
> +
> + ret = devm_add_action_or_reset(dev, imx_rproc_pm_runtime_put, dev);
> + if (ret) {
> + dev_err(dev, "Failed to add devm disable pm action: %d\n", ret);
> + goto err_put_clk;
> + }
> }
>
> ret = rproc_add(rproc);
> @@ -1158,10 +1176,6 @@ static void imx_rproc_remove(struct platform_device *pdev)
> struct rproc *rproc = platform_get_drvdata(pdev);
> struct imx_rproc *priv = rproc->priv;
>
> - if (priv->dcfg->method == IMX_RPROC_SCU_API) {
> - pm_runtime_disable(priv->dev);
> - pm_runtime_put(priv->dev);
> - }
> clk_disable_unprepare(priv->clk);
> rproc_del(rproc);
> imx_rproc_put_scu(rproc);
>
> --
> 2.37.1
>
Powered by blists - more mailing lists