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] [day] [month] [year] [list]
Message-Id: <D681EEAF-A449-4464-80B1-D5B73E53B042@linux.dev>
Date: Tue, 23 Dec 2025 14:23:01 +0100
From: Thorsten Blum <thorsten.blum@...ux.dev>
To: David Laight <david.laight.linux@...il.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
 Viresh Kumar <viresh.kumar@...aro.org>,
 Thomas Renninger <trenn@...e.de>,
 Borislav Petkov <bp@...e.de>,
 Jacob Shin <jacob.shin@....com>,
 stable@...r.kernel.org,
 "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
 linux-pm@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cpufreq: amd_freq_sensitivity: Fix sensitivity clamping
 in amd_powersave_bias_target

On 19. Dec 2025, at 16:55, Thorsten Blum wrote:
> On 2. Dec 2025, at 20:09, David Laight wrote:
>> On Tue,  2 Dec 2025 13:44:28 +0100
>> Thorsten Blum <thorsten.blum@...ux.dev> wrote:
>> 
>>> The local variable 'sensitivity' was never clamped to 0 or
>>> POWERSAVE_BIAS_MAX because the return value of clamp() was not used. Fix
>>> this by assigning the clamped value back to 'sensitivity'.
>> 
>> This actually makes no difference
>> (assuming od_tuners->powersave_bias <= POWERSAVE_BIAS_MAX).
>> The only use of 'sensitivity' is the test at the end of the diff.
>> 
>> So I think you could just delete the line.
> 
> The local variable 'sensitivity' is an 'int', while '->powersave_bias'
> is an 'unsigned int'. If 'sensitivity' were ever negative, it would be
> converted to an 'unsigned int', producing an incorrect result. That's
> probably what the clamping was meant to prevent.
> 
> However, calculating 'sensitivity' can be simplified from:
> 
> 	sensitivity = POWERSAVE_BIAS_MAX -
> 		(POWERSAVE_BIAS_MAX * (d_reference - d_actual) / d_reference);
> 
> to:
> 
> 	sensitivity = POWERSAVE_BIAS_MAX * d_actual / d_reference;
> 
> which makes it clearer that, in practice, 'sensitivity' is never
> negative. How about simplifying the formula as above, changing
> 'sensitivity' to 'unsigned int', and removing the clamping?

Hm, changing the formula could alter the integer arithmetic, potentially
producing slightly different results, and might even overflow.

I guess we should keep the formula as is and either defensively clamp
'sensitivity', as originally intended, or just remove the line (since
this seems to have been working since 2013 and as suggested by David).

I'm slightly in favor of clamping the value because the assumptions
aren't obvious to me.

Any preferences or other suggestions?

Thanks,
Thorsten


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ