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: <b72c666e-b286-45b6-92d9-7c6dfe5753eb@kylinos.cn>
Date: Thu, 21 Aug 2025 17:45:24 +0800
From: Zihuan Zhang <zhangzihuan@...inos.cn>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: "rafael J . wysocki" <rafael@...nel.org>,
 zhenglifeng <zhenglifeng1@...wei.com>, linux-pm@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] cpufreq: simplify setpolicy/target check in driver
 verification


在 2025/8/21 17:17, Viresh Kumar 写道:
> On 21-08-25, 17:00, Zihuan Zhang wrote:
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index a067b5447fe8..92633ff2c4f3 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -2908,6 +2908,8 @@ static int cpuhp_cpufreq_offline(unsigned int cpu)
>>   int cpufreq_register_driver(struct cpufreq_driver *driver_data)
>>   {
>>   	unsigned long flags;
> driver_data can be NULL here. It is checked at a later point.
>
Thanks for your feedback. I did think about the case where driver_data 
is NULL, but I didn’t think it through properly at the time.

You are right — this clearly can cause issues.

>> +	bool has_setpolicy = driver_data->setpolicy;
> This is a pointer and ..
>
>> +	bool has_target = driver_data->target_index || driver_data->target;
> .. this is bool.
>
> Their comparison will always fail. Did you actually try this with both
> setpolicy and target() set for a cpufreq driver to check if it really
> fails ?
>
> What you need is:
>
> 	bool has_setpolicy = !!driver_data->setpolicy;
Sorry about that. I only tested the case where driver registration succeeds.

Do you have any suggestions on how to better test or handle the cases 
where driver registration could fail?
>>   	int ret;
>>   
>>   	if (cpufreq_disabled())
>> @@ -2921,10 +2923,7 @@ int cpufreq_register_driver(struct cpufreq_driver *driver_data)
>>   		return -EPROBE_DEFER;
>>   
>>   	if (!driver_data || !driver_data->verify || !driver_data->init ||
>> -	    !(driver_data->setpolicy || driver_data->target_index ||
>> -		    driver_data->target) ||
>> -	     (driver_data->setpolicy && (driver_data->target_index ||
>> -		    driver_data->target)) ||
>> +	     (has_setpolicy == has_target) ||
> I would rather do:
>
> 	(!!driver_data->setpolicy == (driver_data->target_index || driver_data->target))

The current version of the code is much better and safer.

Thanks for pointing this out.

I will carefully test all cases, including potential failure paths, and 
send a next version accordingly.

>>   	     (!driver_data->get_intermediate != !driver_data->target_intermediate) ||
>>   	     (!driver_data->online != !driver_data->offline) ||
>>   		 (driver_data->adjust_perf && !driver_data->fast_switch))
>> -- 
>> 2.25.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ