linux-kernel - Re: [PATCH V4 2/7] cpufreq: Call __cpufreq

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: <CAJZ5v0hVhVyDvk1Vj5NAh1w1nXEZ6eF0v9x+8CfZ6pyKSu=k9g@mail.gmail.com>
Date:	Thu, 11 Feb 2016 10:48:20 +0100
From:	"Rafael J. Wysocki" <rafael@...nel.org>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	Rafael Wysocki <rjw@...ysocki.net>,
	Juri Lelli <juri.lelli@....com>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Shilpasri G Bhat <shilpa.bhat@...ux.vnet.ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V4 2/7] cpufreq: Call __cpufreq_governor() with
 policy->rwsem held

On Tue, Feb 9, 2016 at 4:46 AM, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> This isn't followed properly by all parts of the core code, some follow
> it, whereas others don't.

"The cpufreq core code is not consistent with respect to invoking
__cpufreq_governor() under policy->rwsem."

> Enforcing it will also enable us to remove cpufreq_governor_lock, that
> is used today because we can't guarantee that __cpufreq_governor() isn't
> executed in parallel.

"Changing all code to always hold policy->rwsem around
__cpufreq_governor() invocations will allow us to ..."

> We should also ensure that the lock is held across state changes to the
> governors.
>
> For example, while adding a CPU to the policy on cpu-online path, we
> need to stop the governor, change policy->cpus, start the governor and
> then refresh its limits. The complete sequence must be guaranteed to
> execute without any concurrent races. And that can be achieved using
> policy->rwsem around these use cases.
>
> Also note that cpufreq_driver->stop_cpu() and ->exit() can get called
> while policy->rwsem is held. That shouldn't have any side effects
> though.

The last paragraph is unclear.

Is it supposed to mean that the change will cause
cpufreq_driver->stop_cpu() and ->exit() to be called under
policy->rwsem sometimes?

Thanks,
Rafael