On 31 January 2015 at 04:27, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html