linux-kernel - Re: [PATCH 01/14] cpufreq/amd-pstate: Show a warning when a CPU fails to setup

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: <584c3152-e730-4cbf-a79e-aa5404de6ab5@kernel.org>
Date: Mon, 10 Feb 2025 09:13:25 -0600
From: Mario Limonciello <superm1@...nel.org>
To: "Gautham R. Shenoy" <gautham.shenoy@....com>,
 Dhananjay Ugwekar <Dhananjay.Ugwekar@....com>
Cc: Perry Yuan <perry.yuan@....com>,
 "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>
Subject: Re: [PATCH 01/14] cpufreq/amd-pstate: Show a warning when a CPU fails
 to setup

On 2/10/2025 07:50, Gautham R. Shenoy wrote:
> On Mon, Feb 10, 2025 at 05:29:24PM +0530, Dhananjay Ugwekar wrote:
>> On 2/7/2025 3:26 AM, Mario Limonciello wrote:
>>> From: Mario Limonciello <mario.limonciello@....com>
>>>
>>> I came across a system that MSR_AMD_CPPC_CAP1 for some CPUs isn't
>>> populated.  This is an unexpected behavior that is most likely a
>>> BIOS bug. In the event it happens I'd like users to report bugs
>>> to properly root cause and get this fixed.
>>
>> I'm okay with this patch, but I see a similar pr_debug in caller cpufreq_online(),
>> so not sure if this is strictly necessary.
>>
>> 1402                 /*
>> 1403                  * Call driver. From then on the cpufreq must be able
>> 1404                  * to accept all calls to ->verify and ->setpolicy for this CPU.
>> 1405                  */
>> 1406                 ret = cpufreq_driver->init(policy);
>> 1407                 if (ret) {
>> 1408                         pr_debug("%s: %d: initialization failed\n", __func__,
>> 1409                                  __LINE__);
>> 1410                         goto out_free_policy;
>> 1411
>>
> 
> Well, the pr_debug() doesn't always get printed unless the loglevel is
> set to debug, which is usually done by the developers and not the end
> users.
> 
> However you have a point that since the code jumps to free_cpudata1 on
> failures from amd_pstate_init_perf(), amd_pstate_init_freq(),
> amd_pstate_init_boost_support(), freq_qos_add_request(). So the
> pr_warn() doesn't indicate that the failure is due to
> MSR_AMD_CPPC_CAP1 not being populated.
> 

Right; my point is that without the warning no one knows there is a problem.

I don't expect we can anticipate all the potential causes, and I want 
anyone who hits this to raise a bug and we can ask them to turn on 
dynamic debug / ftrace and then triage it.