Re: [patch 1/4] cpufreq: Eliminate the recent lockdep warnings in cpufreq

[Thomas Renninger <trenn-l3A5Bk7waGM@public.gmane.org>]

On Friday 03 July 2009 16:28:43 Pallipadi, Venkatesh wrote:
> 
...
> >I still do not see the need of "dbs_mutex protects data in 
> >dbs_tuners_ins
> >from concurrent changes", though. If someone enlightens me, that would
> >be appreciated.
> 
> OK. Consider these two happening in parallel.
> echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice
> echo 1 > /sys/devices/system/cpu/cpu4/cpufreq/ondemand/ignore_nice
Hm, I just consider parallel configuration, especially with different
values as a userspace bug anyway.

> As they are coming from different cpu, rwsem wont protect us and 
> without the dbs_mutex, end state after this can will be unpredictable.
> prev_cpu_idle and prev_cpu_nice can end up with wrong values where
> only one of them is set etc. That will affect the ondemand algorithm.
For one sample in this case.
But I see that it should be made 100%
bulletproof and even userspace is doing wrong things already you want to
have a defined state. A separate mutex, uncoupled from .governor() would make 
things easier, but I wait until it's clear what cleanups are going into which 
kernel and will suggest another cleanup to only allow
global dbs_tuners on top for .31 or further future.

Thanks,

    Thomas