lkml.org 
[lkml]   [2009]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 2/3] cpufreq: Define dbs_mutex purpose and cleanup its usage
    * Pallipadi, Venkatesh (venkatesh.pallipadi@intel.com) wrote:
    > On Thu, 2009-06-25 at 12:46 -0700, Mathieu Desnoyers wrote:
    > > * venkatesh.pallipadi@intel.com (venkatesh.pallipadi@intel.com) wrote:
    > > > Commit b14893a62c73af0eca414cfed505b8c09efc613c although it was very
    > > > much needed to cleanup ondemand timer cleanly, openup a can of worms
    > > > related to locking dependencies in cpufreq.
    > > >
    > > > Patch here defines the need for dbs_mutex and cleans up its usage in
    > > > ondemand governor. This also resolves the lockdep warnings reported here
    > > >
    > > > http://lkml.indiana.edu/hypermail/linux/kernel/0906.1/01925.html
    > > >
    >
    > > > @@ -598,14 +593,16 @@ static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
    > > > max(min_sampling_rate,
    > > > latency * LATENCY_MULTIPLIER);
    > > > }
    > > > + mutex_unlock(&dbs_mutex);
    > > > +
    > > > dbs_timer_init(this_dbs_info);
    > > >
    > > > - mutex_unlock(&dbs_mutex);
    > > > break;
    > > >
    > > > case CPUFREQ_GOV_STOP:
    > > > - mutex_lock(&dbs_mutex);
    > > > dbs_timer_exit(this_dbs_info);
    > >
    > > Hrm, so.. how do we protect against concurrent :
    > >
    > > CPUFREQ_GOV_START/CPUFREQ_GOV_STOP now ?
    >
    > concurrent _START _STOP across CPUs does not matter for timer_init and
    > timer_exit.

    Given those are per-cpu anyway I guess. Hopefully it works OK with CPU
    hotplug.

    > On same CPU, there cannot be two concurrent _START as upper
    > level cpufreq will have policy_rwsem in write mode.

    Agreed.

    > I cannot think of a
    > flow where _START and _STOP on same CPU is possible.
    >

    _STOP is not protected by any mutex now. So it could be preempted, and
    then a _START executed, and there is your race.

    > However two concurrent _STOP for same CPU is still possible, as we are
    > releasing the rwsem lock before STOP callback. "Back to drawing board"
    > time to figure this all out..

    I fear that it is indeed the case. If you can come up with a document
    explaining the expected interactions between :

    - cpu hotplug
    - policy lock
    - cpufreq driver lock
    - timer lock

    that would be awesome. :)

    Mathieu

    >
    > Thanks,
    > Venki
    >

    --
    Mathieu Desnoyers
    OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68


    \
     
     \ /
      Last update: 2009-06-25 23:35    [W:0.037 / U:30.752 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site