Conversion of target_freq to HZ in scmi_cpufreq_fast_switch()
can lead to overflow if the multiplied result is greater than
UINT_MAX, since type of target_freq is unsigned int. Avoid this
overflow by assigning target_freq to unsigned long variable for
converting it to HZ.
Signed-off-by: Jagadeesh Kona <[email protected]>
---
Changes in V2:
- Updated freq variable from u64 to unsigned long to keep it
consistent with the rate parameter in scmi .freq_set() callback
- Link to v1: https://lore.kernel.org/all/[email protected]/
---
drivers/cpufreq/scmi-cpufreq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index 3b4f6bfb2f4c..b87fd127aa43 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -63,9 +63,9 @@ static unsigned int scmi_cpufreq_fast_switch(struct cpufreq_policy *policy,
unsigned int target_freq)
{
struct scmi_data *priv = policy->driver_data;
+ unsigned long freq = target_freq;
- if (!perf_ops->freq_set(ph, priv->domain_id,
- target_freq * 1000, true))
+ if (!perf_ops->freq_set(ph, priv->domain_id, freq * 1000, true))
return target_freq;
return 0;
--
2.43.0
On 20-05-24, 12:07, Jagadeesh Kona wrote:
> Conversion of target_freq to HZ in scmi_cpufreq_fast_switch()
> can lead to overflow if the multiplied result is greater than
> UINT_MAX, since type of target_freq is unsigned int. Avoid this
> overflow by assigning target_freq to unsigned long variable for
> converting it to HZ.
>
> Signed-off-by: Jagadeesh Kona <[email protected]>
> ---
> Changes in V2:
> - Updated freq variable from u64 to unsigned long to keep it
> consistent with the rate parameter in scmi .freq_set() callback
> - Link to v1: https://lore.kernel.org/all/[email protected]/
> ---
> drivers/cpufreq/scmi-cpufreq.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied. Thanks.
--
viresh
On 5/20/2024 2:17 PM, Viresh Kumar wrote:
> On 20-05-24, 12:07, Jagadeesh Kona wrote:
>> Conversion of target_freq to HZ in scmi_cpufreq_fast_switch()
>> can lead to overflow if the multiplied result is greater than
>> UINT_MAX, since type of target_freq is unsigned int. Avoid this
>> overflow by assigning target_freq to unsigned long variable for
>> converting it to HZ.
>>
>> Signed-off-by: Jagadeesh Kona <[email protected]>
>> ---
>> Changes in V2:
>> - Updated freq variable from u64 to unsigned long to keep it
>> consistent with the rate parameter in scmi .freq_set() callback
>> - Link to v1: https://lore.kernel.org/all/[email protected]/
>> ---
>> drivers/cpufreq/scmi-cpufreq.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Applied. Thanks.
>
Thanks Viresh for the offline update on applying this patch to cpufreq
arm tree. Please help share the git tree details of the same, since we
need them to pick this change in Google ACK and downstream tree.
Thanks,
Jagadeesh
On 27-05-24, 15:26, Jagadeesh Kona wrote:
>
>
> On 5/20/2024 2:17 PM, Viresh Kumar wrote:
> > On 20-05-24, 12:07, Jagadeesh Kona wrote:
> > > Conversion of target_freq to HZ in scmi_cpufreq_fast_switch()
> > > can lead to overflow if the multiplied result is greater than
> > > UINT_MAX, since type of target_freq is unsigned int. Avoid this
> > > overflow by assigning target_freq to unsigned long variable for
> > > converting it to HZ.
> > >
> > > Signed-off-by: Jagadeesh Kona <[email protected]>
> > > ---
> > > Changes in V2:
> > > - Updated freq variable from u64 to unsigned long to keep it
> > > consistent with the rate parameter in scmi .freq_set() callback
> > > - Link to v1: https://lore.kernel.org/all/[email protected]/
> > > ---
> > > drivers/cpufreq/scmi-cpufreq.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > Applied. Thanks.
> >
>
> Thanks Viresh for the offline update on applying this patch to cpufreq arm
> tree. Please help share the git tree details of the same, since we need them
> to pick this change in Google ACK and downstream tree.
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git cpufreq/arm/linux-next
I have pushed it out now, it will be there in linux-next soon. My
branch is not fixed, I may end up rebasing it. Ideally, you shouldn't
backport anything to android unless it end ups in Linus's tree, only
then the sha id will be fixed and guaranteed not to change.
--
viresh
On 5/28/2024 9:33 AM, Viresh Kumar wrote:
> On 27-05-24, 15:26, Jagadeesh Kona wrote:
>>
>>
>> On 5/20/2024 2:17 PM, Viresh Kumar wrote:
>>> On 20-05-24, 12:07, Jagadeesh Kona wrote:
>>>> Conversion of target_freq to HZ in scmi_cpufreq_fast_switch()
>>>> can lead to overflow if the multiplied result is greater than
>>>> UINT_MAX, since type of target_freq is unsigned int. Avoid this
>>>> overflow by assigning target_freq to unsigned long variable for
>>>> converting it to HZ.
>>>>
>>>> Signed-off-by: Jagadeesh Kona <[email protected]>
>>>> ---
>>>> Changes in V2:
>>>> - Updated freq variable from u64 to unsigned long to keep it
>>>> consistent with the rate parameter in scmi .freq_set() callback
>>>> - Link to v1: https://lore.kernel.org/all/[email protected]/
>>>> ---
>>>> drivers/cpufreq/scmi-cpufreq.c | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> Applied. Thanks.
>>>
>>
>> Thanks Viresh for the offline update on applying this patch to cpufreq arm
>> tree. Please help share the git tree details of the same, since we need them
>> to pick this change in Google ACK and downstream tree.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git cpufreq/arm/linux-next
>
> I have pushed it out now, it will be there in linux-next soon. My
> branch is not fixed, I may end up rebasing it. Ideally, you shouldn't
> backport anything to android unless it end ups in Linus's tree, only
> then the sha id will be fixed and guaranteed not to change.
>
Thanks Viresh!