Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jiaxing Hu" <gahing@gahingwoo.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org,
	dri-devel@lists.freedesktop.org, conor+dt@kernel.org
Subject: Re: [PATCH v11 10/14] pmdomain/rockchip: cycle optional power-domain resets on power-on
Date: Mon, 31 Aug 2026 09:05:06 +0000	[thread overview]
Message-ID: <20260831090507.54F3D1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260831081956.84871-11-gahing@gahingwoo.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Resource leak of clock references on of_clk_get failure
- [High] Use-after-free when pm_genpd_remove fails during probe error cleanup
--

commit c4349e9db6c9eecdba71ab60966e3312c6588638
Author: Jiaxing Hu <gahing@gahingwoo.com>

pmdomain/rockchip: cycle optional power-domain resets on power-on

Some Rockchip domains come out of power-on with their bus interface in
an undefined state. On the RK3576 NPU this shows up as a hang on the
first register access after the domain is switched on, and pulsing the
domain's resets at this point clears it.

Take the domain node's resets if it has any, and pulse them between
releasing idle and restoring QoS. The resets are optional, so domains
that do not list any are unaffected.

> diff --git a/drivers/pmdomain/rockchip/pm-domains.c b/drivers/pmdomain/rockchip/pm-domains.c
> index 39988efd86aaa..8f2fd8a83e8e9 100644
> --- a/drivers/pmdomain/rockchip/pm-domains.c
> +++ b/drivers/pmdomain/rockchip/pm-domains.c

[ ... ]

> @@ -861,6 +870,14 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu,
>  	if (error)
>  		goto err_put_clocks;

[Severity: High]
This isn't a bug introduced by this patch, but does this code leak the
clocks on of_clk_get() failure?

Looking at rockchip_pm_add_one_domain(), just above this code:

	for (i = 0; i < pd->num_clks; i++) {
		pd->clks[i].clk = of_clk_get(node, i);
		if (IS_ERR(pd->clks[i].clk)) {
			error = PTR_ERR(pd->clks[i].clk);
			dev_err(pmu->dev,
				"%pOFn: failed to get clk at index %d: %d\n",
				node, i, error);
			return error;
		}
	}

If a PM domain has multiple clocks defined in its device tree node, and
of_clk_get() succeeds for the first clock(s) but fails for a subsequent
clock (e.g., returning -EPROBE_DEFER), the function returns the error
directly without calling clk_put() on the successfully acquired clocks.

Could this direct return bypass the err_put_clocks cleanup path and leak
the clocks acquired in previous loop iterations?

> +	pd->resets = of_reset_control_array_get_optional_exclusive(node);
> +	if (IS_ERR(pd->resets)) {
> +		error = dev_err_probe(pmu->dev, PTR_ERR(pd->resets),
> +				      "%pOFn: failed to get resets\n", node);
> +		pd->resets = NULL;
> +		goto err_unprepare_clocks;
> +	}
> +
>  	pd->num_qos = of_count_phandle_with_args(node, "pm_qos",
>  						 NULL);

[ ... ]

> @@ -949,6 +967,7 @@ static void rockchip_pm_remove_one_domain(struct rockchip_pm_domain *pd)
>  
>  	clk_bulk_unprepare(pd->num_clks, pd->clks);
>  	clk_bulk_put(pd->num_clks, pd->clks);

[Severity: High]
This is a pre-existing issue, but can this lead to a use-after-free when
pm_genpd_remove() fails during probe error cleanup?

In rockchip_pm_remove_one_domain(), right before this code:

	ret = pm_genpd_remove(&pd->genpd);
	if (ret < 0)
		dev_err(pd->pmu->dev, "failed to remove domain '%s' : %d - state may be inconsistent\n",
			pd->genpd.name, ret);

If rockchip_pm_add_subdomain() or pm_genpd_provider_add_of() fails,
rockchip_pm_domain_cleanup() iterates over all domains in reg ID order.
If a child domain has a smaller ID than its parent, the child is removed
first. Because its parent link still exists, pm_genpd_remove() returns
-EBUSY and fails to remove the child from the global gpd_list.

Despite the failure, rockchip_pm_remove_one_domain() returns and the
rockchip_pm_domain structure is freed by devm when the probe fails.

Does this leave a pointer to freed memory in the global gpd_list, leading
to a use-after-free when the list is next accessed (e.g., by
genpd_power_off_unused())?

> +	reset_control_put(pd->resets);
>  
>  	/* protect the zeroing of pm->num_clks */
>  	mutex_lock(&pd->pmu->mutex);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831081956.84871-1-gahing@gahingwoo.com?part=10

  reply	other threads:[~2026-08-31  9:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31  8:19 [PATCH v11 00/14] accel/rocket: RK3576 NPU (RKNN) enablement Jiaxing Hu
2026-08-31  8:19 ` [PATCH v11 01/14] accel/rocket: request the core clocks by name Jiaxing Hu
2026-08-31  8:36   ` sashiko-bot
2026-08-31  8:19 ` [PATCH v11 02/14] accel/rocket: take the completion register writes under job_lock Jiaxing Hu
2026-08-31  8:36   ` sashiko-bot
2026-08-31  8:19 ` [PATCH v11 03/14] accel/rocket: wait for a running IRQ handler before resetting a core Jiaxing Hu
2026-08-31  8:37   ` sashiko-bot
2026-08-31  8:19 ` [PATCH v11 04/14] accel/rocket: let the core suspend after a reset Jiaxing Hu
2026-08-31  8:49   ` sashiko-bot
2026-08-31  8:19 ` [PATCH v11 05/14] accel/rocket: factor the completion tail out of the IRQ handler Jiaxing Hu
2026-08-31  8:52   ` sashiko-bot
2026-08-31  8:19 ` [PATCH v11 06/14] dt-bindings: npu: rockchip: add rockchip,rk3576-rknn-core Jiaxing Hu
2026-08-31  8:19 ` [PATCH v11 07/14] dt-bindings: power: rockchip: allow resets in a power domain node Jiaxing Hu
2026-08-31  8:19 ` [PATCH v11 08/14] dt-bindings: iommu: rockchip: describe the RK3576 NPU MMU Jiaxing Hu
2026-08-31  8:19 ` [PATCH v11 09/14] pmdomain/rockchip: add optional per-domain power-on settle delay Jiaxing Hu
2026-08-31  8:19 ` [PATCH v11 10/14] pmdomain/rockchip: cycle optional power-domain resets on power-on Jiaxing Hu
2026-08-31  9:05   ` sashiko-bot [this message]
2026-08-31  8:19 ` [PATCH v11 11/14] accel/rocket: select the per-core clock and reset counts from match data Jiaxing Hu
2026-08-31  9:04   ` sashiko-bot
2026-08-31  8:19 ` [PATCH v11 12/14] accel/rocket: add RK3576 NPU (RKNN) support Jiaxing Hu
2026-08-31  9:11   ` sashiko-bot
2026-08-31  8:19 ` [PATCH v11 13/14] arm64: dts: rockchip: rk3576: add NPU (RKNN) nodes Jiaxing Hu
2026-08-31  9:16   ` sashiko-bot
2026-08-31  8:19 ` [PATCH v11 14/14] arm64: dts: rockchip: rk3576-rock-4d: enable NPU Jiaxing Hu

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=20260831090507.54F3D1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gahing@gahingwoo.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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