On 06/04/2015 12:43 PM, Viresh Kumar wrote:
On 04-06-15, 12:34, Preeti U Murthy wrote:
My point is do we really need to treat them as separate problems ?
Yes.
Will not serializing sequence of events help solve both issues ?
That's not the point. Even if it solves the problem, it may not be the right approach. There are two problems here:
- One lies in cpufreq.c or in policies domain.
- Other one is about governor. Governor code shouldn't rely of cpufreq.c locking to guarantee that access to its structures isn't racy.
And the way you proposed to solve it (yes the original idea was from one of my earlier patches) is not the right way to do it.
For example, cpufreq_set_policy() shouldn't care about how the governor code is placed. It should just do enough to get rid of racy code belonging to that policy.
But with our other approach, we are trying to stop the governor to be used by anyone else in the kernel. Who the hell is that 'policy' to decide who can access the governor ?
That's why I divided it up, so that we don't come to it again. I haven't learnt these things earlier, and wrote messy locking code earlier. But after looking/working on core code like timers etc, I understood the importance of right design and proper partitioning of responsibilities.
Ok, fair enough.
Regards Preeti U Murthy