Re: [PATCH 0/3] cpufreq: governor: Fix potential races

[Preeti U Murthy <preeti@linux.vnet.ibm.com>]

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