linux-kernel - Re: [PATCH v2] cpufreq: Remove 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] [day] [month] [year] [list]

Message-ID: <3827470.2xPx8lfogL@vostro.rjw.lan>
Date:	Thu, 23 Jul 2015 22:59:53 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, Viresh Kumar <viresh.kumar@...aro.org>
Subject: Re: [PATCH v2] cpufreq: Remove cpufreq_rwsem

On Wednesday, July 22, 2015 05:59:11 PM Sebastian Andrzej Siewior wrote:
> cpufreq_rwsem was introduced in commit 6eed9404ab3c4 ("cpufreq: Use
> rwsem for protecting critical sections) in order to replace
> try_module_get() on the cpu-freq driver. That try_module_get() worked
> well until the refcount was so heavily used that module removal became
> more or less impossible.
> 
> Though when looking at the various (undocumented) protection
> mechanisms in that code, the randomly sprinkeled around cpufreq_rwsem
> locking sites are superfluous.
> 
> The policy, which is acquired in cpufreq_cpu_get() and released in
> cpufreq_cpu_put() is sufficiently protected already.
> 
>   cpufreq_cpu_get(cpu)
>     /* Protects against concurrent driver removal */
>     read_lock_irqsave(&cpufreq_driver_lock, flags);
>     policy = per_cpu(cpufreq_cpu_data, cpu);
>     kobject_get(&policy->kobj);
>     read_unlock_irqrestore(&cpufreq_driver_lock, flags);
> 
> The reference on the policy serializes versus module unload already:
> 
>   cpufreq_unregister_driver()
>     subsys_interface_unregister()
>       __cpufreq_remove_dev_finish()
>         per_cpu(cpufreq_cpu_data) = NULL;
> 	cpufreq_policy_put_kobj()
> 
> If there is a reference held on the policy, i.e. obtained prior to the
> unregister call, then cpufreq_policy_put_kobj() will wait until that
> reference is dropped. So once subsys_interface_unregister() returns
> there is no policy pointer in flight and no new reference can be
> obtained. So that rwsem protection is useless.
> 
> The other usage of cpufreq_rwsem in show()/store() of the sysfs
> interface is redundant as well because sysfs already does the proper
> kobject_get()/put() pairs.
> 
> That leaves CPU hotplug versus module removal. The current
> down_write() around the write_lock() in cpufreq_unregister_driver() is
> silly at best as it protects actually nothing.
> 
> The trivial solution to this is to prevent hotplug across
> cpufreq_unregister_driver completely.
> 
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>

Makes sense.

Queued up for 4.3, thanks!


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/