linux-kernel - Re: [PATCH] cpufreq/amd-pstate: Prefix setup messages with FW

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: <45eeecc0-cc97-4d87-b650-f45c3aa99a67@kernel.org>
Date: Wed, 2 Apr 2025 14:57:18 -0500
From: Mario Limonciello <superm1@...nel.org>
To: Dhananjay Ugwekar <Dhananjay.Ugwekar@....com>,
 "Gautham R . Shenoy" <gautham.shenoy@....com>,
 Perry Yuan <perry.yuan@....com>
Cc: "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
 <linux-kernel@...r.kernel.org>,
 "open list:CPU FREQUENCY SCALING FRAMEWORK" <linux-pm@...r.kernel.org>,
 Mario Limonciello <mario.limonciello@....com>,
 Paul Menzel <pmenzel@...gen.mpg.de>
Subject: Re: [PATCH] cpufreq/amd-pstate: Prefix setup messages with FW_BUG

On 3/28/2025 2:20 AM, Dhananjay Ugwekar wrote:
> On 3/21/2025 3:11 AM, Mario Limonciello wrote:
>> From: Mario Limonciello <mario.limonciello@....com>
>>
>> To make it clearer that amd-pstate failing to setup is a problem
>> with the firmware, prefix several messages with FW_BUG.
>>
>> Suggested-by: Paul Menzel <pmenzel@...gen.mpg.de>
>> Signed-off-by: Mario Limonciello <mario.limonciello@....com>
>> ---
>>   drivers/cpufreq/amd-pstate.c | 6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
>> index 024d33d5e3670..0a9d6fe426d1c 100644
>> --- a/drivers/cpufreq/amd-pstate.c
>> +++ b/drivers/cpufreq/amd-pstate.c
>> @@ -931,13 +931,13 @@ static int amd_pstate_init_freq(struct amd_cpudata *cpudata)
>>   	 * Check _CPC in ACPI table objects if any values are incorrect
>>   	 */
>>   	if (min_freq <= 0 || max_freq <= 0 || nominal_freq <= 0 || min_freq > max_freq) {
>> -		pr_err("min_freq(%d) or max_freq(%d) or nominal_freq(%d) value is incorrect\n",
>> +		pr_err(FW_BUG "min_freq(%d) or max_freq(%d) or nominal_freq(%d) value is incorrect\n",
>>   			min_freq, max_freq, nominal_freq);
>>   		return -EINVAL;
>>   	}
>>   
>>   	if (lowest_nonlinear_freq <= min_freq || lowest_nonlinear_freq > nominal_freq) {
>> -		pr_err("lowest_nonlinear_freq(%d) value is out of range [min_freq(%d), nominal_freq(%d)]\n",
>> +		pr_err(FW_BUG "lowest_nonlinear_freq(%d) value is out of range [min_freq(%d), nominal_freq(%d)]\n",
>>   			lowest_nonlinear_freq, min_freq, nominal_freq);
>>   		return -EINVAL;
>>   	}
>> @@ -1505,7 +1505,7 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
>>   	return 0;
>>   
>>   free_cpudata1:
>> -	pr_warn("Failed to initialize CPU %d: %d\n", policy->cpu, ret);
>> +	pr_warn(FW_BUG "Failed to initialize CPU %d: %d\n", policy->cpu, ret);
> 
> Just thinking are we sure that we land here only through a firmware bug?
> 
> If not, we should probably use FW_WARN ?,
> or
> Should we add to the error message the specific firmware issue that might cause
> each of the functions to fail (e.g. amd_pstate_init_perf(), amd_pstate_init_freq(),
> etc).

I looked at the call paths and I'm not convinced that they will all be 
firmware bugs.  In any case I want to know whenever there is a failure 
here so we can evaluate if it's a firmware bug or a software bug.

If it's a software bug we'll obviously work on it, and if it's a 
firmware bug do our best to notify the firmware developer.

So I will abandon this patch, thanks for the great feedback.

> 
> Comments for the macros, for reference,
> 
>   * FW_BUG
>   * Add this to a message where you are sure the firmware is buggy or behaves
>   * really stupid or out of spec. Be aware that the responsible BIOS developer
>   * should be able to fix this issue or at least get a concrete idea of the
>   * problem by reading your message without the need of looking at the kernel
>   * code.
>   *
>   * Use it for definite and high priority BIOS bugs.
>   *
>   * FW_WARN
>   * Use it for not that clear (e.g. could the kernel messed up things already?)
>   * and medium priority BIOS bugs.
> 
>>   	kfree(cpudata);
>>   	return ret;
>>   }
>