Re: [RFC PATCH 18/19] cpufreq: remove transition_lock

[Viresh Kumar]

On 14-01-16, 13:52, Juri Lelli wrote:
> I was under the impression that the purpose of having
> __cpufreq_driver_target() exported outside cpufreq.c was working due to
> the fact that users implement their own locking.
> 
> That's why I put the following comment in this patch.
> 
>  /*
>   * Callers must ensure proper mutual exclusion on policy (for transition_
>   * ongoing/transition_task handling). While holding policy->rwsem is
>   * sufficient, other schemes might work as well (e.g., cpufreq_governor.c
>   * holds timer_mutex while entering the path that generates transitions).
>   */
> 
> >From what I can see ondemand and conservative (via governor) seem to use
> timer_mutex; userspace userspace_mutex instead. Do they serve different
> purposes instead? How do we currently serialize operations on policy
> when using __cpufreq_driver_target() directly otherwise?

The patch I referred to earlier in the thread had detailed few of the
races we were worried about. The lock you just removed is responsible
for taking care of the races you are worried now :)

-- 
viresh