Messages in this thread | | | Date | Wed, 25 May 2022 11:02:16 +0530 | From | Viresh Kumar <> | Subject | Re: [PATCH v3] cpufreq: fix race on cpufreq online |
| |
On 24-05-22, 13:53, Rafael J. Wysocki wrote: > On Tue, May 24, 2022 at 1:48 PM Rafael J. Wysocki <rafael@kernel.org> wrote: > > So this was done before the entire CPU hotplug rework and it was > > useful at that time. > > > > The current code always runs cpufreq_set_policy() under policy->rwsem > > and governors are stopped under policy->rwsem, so this particular race > > cannot happen AFAICS. > > > > Locking CPU hotplug prevents CPUs from going away while store() is > > running, but in order to run store(), the caller must hold an active > > reference to the policy kobject. That prevents the policy from being > > freed and so policy->rwsem can be acquired. After policy->rwsem has > > been acquired, policy->cpus can be checked to determine whether or not > > there are any online CPUs for the given policy (there may be none), > > because policy->cpus is only manipulated under policy->rwsem. > > > > If a CPU that belongs to the given policy is going away, > > cpufreq_offline() has to remove it from policy->cpus under > > policy->rwsem, so either it has to wait for store() to release > > policy->rwsem, or store() will acquire policy->rwsem after it and will > > find that policy->cpus is empty. > > Moreover, locking CPU hotplug doesn't actually prevent > cpufreq_remove_dev() from running which can happen when the cpufreq > driver is unregistered, for example.
Right, we can get rid of this now I believe.
-- viresh
| |