On 31 January 2015 at 04:27, Rafael J. Wysocki rjw@rjwysocki.net wrote:
No, it isn't. cpufreq_cpu_data is a pointer and doesn't need any locks to protect it. What the lock does is to guarantee the callers of cpufreq_cpu_get() that the policy object won't go away from under them (it is used for some other purposes too, but they are unrelated).
Yeah, its not just locking. Otherwise the locking only at the bottom of this routine should have fixed it.
That's almost correct. In addition to the above (albeit maybe unintentionally) the patch also fixes the possible race between two instances of __cpufreq_remove_dev_finish() with the same arguments running in parallel with each other. The proof is left as an exercise to the reader. :-)
Two __cpufreq_remove_dev_finish() can't get called in parallel, so it doesn't fix any race there :).
Please try to improve the changelog ...
Yes.