linux-kernel - Re: [PATCH v3 03/12] cpufreq: intel_pstate: Use scope-based cleanup helper

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0jvOKeLRkjWoKR5eVKZ-hib7c8D-VOBvtCvs1+HGfPUiQ@mail.gmail.com>
Date: Tue, 2 Sep 2025 13:47:33 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Zihuan Zhang <zhangzihuan@...inos.cn>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Viresh Kumar <viresh.kumar@...aro.org>, 
	Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, 
	Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, 
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>, Michael Ellerman <mpe@...erman.id.au>, 
	Krzysztof Kozlowski <krzk@...nel.org>, Alim Akhtar <alim.akhtar@...sung.com>, 
	Thierry Reding <thierry.reding@...il.com>, MyungJoo Ham <myungjoo.ham@...sung.com>, 
	Kyungmin Park <kyungmin.park@...sung.com>, Chanwoo Choi <cw00.choi@...sung.com>, 
	Jani Nikula <jani.nikula@...ux.intel.com>, Rodrigo Vivi <rodrigo.vivi@...el.com>, 
	Tvrtko Ursulin <tursulin@...ulin.net>, David Airlie <airlied@...il.com>, 
	Simona Vetter <simona@...ll.ch>, Daniel Lezcano <daniel.lezcano@...nel.org>, 
	Sascha Hauer <s.hauer@...gutronix.de>, Shawn Guo <shawnguo@...nel.org>, 
	Eduardo Valentin <edubezval@...il.com>, Keerthy <j-keerthy@...com>, Ben Horgan <ben.horgan@....com>, 
	zhenglifeng <zhenglifeng1@...wei.com>, Zhang Rui <rui.zhang@...el.com>, 
	Len Brown <lenb@...nel.org>, Lukasz Luba <lukasz.luba@....com>, 
	Pengutronix Kernel Team <kernel@...gutronix.de>, Beata Michalska <beata.michalska@....com>, 
	Fabio Estevam <festevam@...il.com>, Pavel Machek <pavel@...nel.org>, Sumit Gupta <sumitg@...dia.com>, 
	Prasanna Kumar T S M <ptsm@...ux.microsoft.com>, Sudeep Holla <sudeep.holla@....com>, 
	Yicong Yang <yangyicong@...ilicon.com>, linux-pm@...r.kernel.org, 
	linux-acpi@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org, 
	linux-arm-kernel@...ts.infradead.org, intel-gfx@...ts.freedesktop.org, 
	dri-devel@...ts.freedesktop.org, imx@...ts.linux.dev, 
	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 03/12] cpufreq: intel_pstate: Use scope-based cleanup helper

On Tue, Sep 2, 2025 at 12:33 PM Zihuan Zhang <zhangzihuan@...inos.cn> wrote:
>
>
> 在 2025/9/1 23:17, Rafael J. Wysocki 写道:
> > On Mon, Sep 1, 2025 at 10:58 AM Zihuan Zhang <zhangzihuan@...inos.cn> wrote:
> >> Replace the manual cpufreq_cpu_put() with __free(put_cpufreq_policy)
> >> annotation for policy references. This reduces the risk of reference
> >> counting mistakes and aligns the code with the latest kernel style.
> >>
> >> No functional change intended.
> >>
> >> Signed-off-by: Zihuan Zhang <zhangzihuan@...inos.cn>
> >> ---
> >>   drivers/cpufreq/intel_pstate.c | 8 +++-----
> >>   1 file changed, 3 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> >> index f366d35c5840..4abc1ef2d2b0 100644
> >> --- a/drivers/cpufreq/intel_pstate.c
> >> +++ b/drivers/cpufreq/intel_pstate.c
> >> @@ -1502,9 +1502,8 @@ static void __intel_pstate_update_max_freq(struct cpufreq_policy *policy,
> >>
> >>   static bool intel_pstate_update_max_freq(struct cpudata *cpudata)
> >>   {
> >> -       struct cpufreq_policy *policy __free(put_cpufreq_policy);
> >> +       struct cpufreq_policy *policy __free(put_cpufreq_policy) = cpufreq_cpu_get(cpudata->cpu);
> >>
> >> -       policy = cpufreq_cpu_get(cpudata->cpu);
> >>          if (!policy)
> >>                  return false;
> > The structure of the code is intentional here and there's no reason to
> > change it.
>
>
> Got it. Thanks for clarifying.
>
> So for this case the current structure is intentional -

Note that I'm talking about this particular change only.  The other
change in the $subject patch is fine.

> should I also avoid similar changes in other drivers?

That depends on who maintains them, which is why I wanted you to split
the patch into smaller changes in the first place.

My personal view is that code formatting changes, which effectively is
what this particular one is, are pointless unless they make the code
much easier to follow.