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: <20200730064112.lvbwas7zzqruvprk@vireshk-mac-ubuntu>
Date:   Thu, 30 Jul 2020 12:11:12 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Amit Kucheria <amitk@...nel.org>
Cc:     Rafael Wysocki <rjw@...ysocki.net>, Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Linux PM list <linux-pm@...r.kernel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        ionela.voinescu@....com,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] cpufreq: cached_resolved_idx can not be negative

On 30-07-20, 12:02, Amit Kucheria wrote:
> Looking at this more closely, I found another call site for
> cpufreq_frequency_table_target() in cpufreq.c that needs the index to
> be unsigned int.
> 
> But then cpufreq_frequency_table_target() returns -EINVAL, so we

It returns -EINVAL only in the case where the relation is not valid,
which will never happen. Maybe that should be marked with WARN or BUG
and we should drop return value of -EINVAL.

Rafael ?

> should be able to handle int values.

And so no.

> I think you will need to fix the unconditional assignment of
>     policy->cached_resolved_idx = idx
> in cpufreq_driver_resolve_freq(). It doesn't check for -EINVAL, so the
> qcom driver is write in checking for a negative value.

Right, I don't want it to have that check for the reason stated above.

The point is I don't want code that verifies cached-idx at all, it is
useless.

-- 
viresh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ