linux-kernel - Re: [PATCH V3 3/3] arm64: topology: Make AMUs work with modular cpufreq drivers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210108094416.GA19952@arm.com>
Date:   Fri, 8 Jan 2021 09:44:17 +0000
From:   Ionela Voinescu <ionela.voinescu@....com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3 3/3] arm64: topology: Make AMUs work with modular
 cpufreq drivers

On Thursday 17 Dec 2020 at 16:20:49 (+0530), Viresh Kumar wrote:
> On 16-12-20, 19:37, Ionela Voinescu wrote:
> > I did not yet test this, but reading this comment made me wonder..
> > 
> > arch_scale_freq_invariant() (or topology_scale_freq_invariant()) is also
> > called from schedutil when obtaining the next frequency.
> > 
> > So if we had a system that only partly supports AMUs but had at some
> > point a cpufreq driver that provided FIE for the other CPUs, when we
> > unregister the driver, the cpufreq_freq_invariance static key is
> > disabled. Therefore, none of the conditions for system invariance is
> > now accomplished and arch_scale_freq_invariant() will return false.
> > This will be broken as utilization is still scaled, but the algorithm
> > for computing the next frequency in schedutil will not take this into
> > account.
> 
> I think the best and the easiest solution for this is:
> 
> bool arch_freq_counters_available(const struct cpumask *cpus)
> {
>         return amu_freq_invariant();
> }
> 
> But we probably need to rename it to something like arch_is_fie().
> 

Now that I think of it again (after spending 30 minutes trying to come
up with a more clear solution) I realised this is not actually a
problem :).

The only location that checks the invariance status is schedutil, but
what a cpufreq governor does becomes irrelevant if you remove the
cpufreq driver. The only potential problem is if one then inmods a
cpufreq driver that's not invariant. But I think that might be on "if"
too many to consider. What do you think?

Thanks,
Ionela.