[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b0e52380c54775073d44bc97f823ec4f@linux.dev>
Date: Thu, 30 Mar 2023 01:39:18 +0000
From: "Yajun Deng" <yajun.deng@...ux.dev>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: viresh.kumar@...aro.org, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cpufreq: Fix policy->freq_table is NULL in
__cpufreq_driver_target()
March 29, 2023 10:21 PM, "Rafael J. Wysocki" <rafael@...nel.org> wrote:
> On Wed, Mar 29, 2023 at 3:36 PM Yajun Deng <yajun.deng@...ux.dev> wrote:
>
>> __resolve_freq() may be return target_freq if policy->freq_table is
>> NULL. In this case, it should return -EINVAL before __target_index().
>
> Even so, __target_index() itself doesn't dereference freq_table
> AFAICS, so arguably the driver should be prepared to deal with a NULL
> freq_table which comes from it after all.
>
But there is a statement 'unsigned int newfreq = policy->freq_table[index].frequency;'
in __target_index(), if driver doesn't provide freq_table, __target_index()
will fault before the driver itself.
> Or, if you want to argue that drivers providing ->target_index() must
> also provide freq_table that is not NULL, a check to that effect needs
> to be done at the driver registration time IMO.
>
>> Signed-off-by: Yajun Deng <yajun.deng@...ux.dev>
>> ---
>> drivers/cpufreq/cpufreq.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index c0e5be0fe2d6..308a3df1a940 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -2299,7 +2299,7 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
>> return cpufreq_driver->target(policy, target_freq, relation);
>> }
>>
>> - if (!cpufreq_driver->target_index)
>> + if (!cpufreq_driver->target_index || !policy->freq_table)
>> return -EINVAL;
>>
>> return __target_index(policy, policy->cached_resolved_idx);
>> --
Powered by blists - more mailing lists