Re: [PATCH 4/5] devfreq: Use %pe to print error pointers symbolically

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Mixing devm-managed devfreq devices with manual resource cleanup creates a Use-After-Free window where the devfreq governor remains active.
--

commit 1c53c8340b588403af3236e1cac077099e3f1d6f
Author: Sumeet Pawnikar <sumeet4linux@gmail.com>

devfreq: Use %pe to print error pointers symbolically

This commit replaces PTR_ERR() and %ld with the %pe format specifier for
printing error pointers in several devfreq drivers. It allows dev_err() to
print symbolic error names when enabled, falling back to the raw integer value
otherwise.

> diff --git a/drivers/devfreq/mtk-cci-devfreq.c b/drivers/devfreq/mtk-cci-devfreq.c
> index 4c22be728f6a0..bda788909887e 100644
> --- a/drivers/devfreq/mtk-cci-devfreq.c
> +++ b/drivers/devfreq/mtk-cci-devfreq.c
> @@ -364,8 +364,8 @@ static int mtk_ccifreq_probe(struct platform_device *pdev)
>  					       passive_data);
>  	if (IS_ERR(drv->devfreq)) {
>  		ret = -EPROBE_DEFER;
> -		dev_err(dev, "failed to add devfreq device: %ld\n",
> -			PTR_ERR(drv->devfreq));
> +		dev_err(dev, "failed to add devfreq device: %pe\n",
> +			drv->devfreq);
>  		goto out_remove_opp_table;
>  	}
>  

[Severity: High]
This is a pre-existing issue, but mixing devm-managed devfreq devices with
manual resource cleanup appears to create a use-after-free window where the
devfreq governor remains active.

In mtk_ccifreq_probe(), if dev_pm_opp_register_notifier() fails later in the
function, it jumps to the cleanup code:

mtk_ccifreq_probe() {
    ...
    drv->devfreq = devm_devfreq_add_device(...);
    ...
    ret = dev_pm_opp_register_notifier(dev, &drv->opp_nb);
    if (ret) {
        ...
        goto out_remove_opp_table;
    }
    return 0;

out_remove_opp_table:
	dev_pm_opp_of_remove_table(dev);

out_disable_cci_clk:
	clk_disable_unprepare(drv->cci_clk);
    ...
}

This manual cleanup is performed before devres cleans up the devm-managed
devfreq device. Since the passive governor registers a CPU frequency notifier,
could a background CPU frequency transition during this window trigger the
target callback on freed OPP tables and disabled hardware, potentially leading
to a kernel panic?

A similar issue appears to exist in mtk_ccifreq_remove(), where manual cleanup
occurs before devres stops the devfreq passive governor.

Additionally, in imx_bus_probe() in drivers/devfreq/imx-bus.c, the error path
manual cleanup creates a use-after-free window for the still-active devfreq
device. Since it uses the userspace governor, does this make it susceptible
to sysfs writes during module removal or probe failures?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260906061755.5103-1-sumeet4linux@gmail.com?part=4