lkml.org 
[lkml]   [2006]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.16-rc1-mm1
    On Wed, Jan 18, 2006 at 03:27:16AM -0800, Andrew Morton wrote:

    > Well yes, that code is kfree()ing a locked mutex. It's somewhat weird to
    > take a lock on a still-private object but whatever. The code's legal
    > enough.
    >
    >
    > --- devel/drivers/cpufreq/cpufreq.c~cpufreq-mutex-locking-fix 2006-01-18 03:25:33.000000000 -0800
    > +++ devel-akpm/drivers/cpufreq/cpufreq.c 2006-01-18 03:25:55.000000000 -0800
    > @@ -674,6 +674,7 @@ err_out_driver_exit:
    > cpufreq_driver->exit(policy);
    >
    > err_out:
    > + mutex_unlock(&policy->lock);
    > kfree(policy);
    >

    This looks odd, because we do this..

    mutex_unlock(&policy->lock);

    /* set default policy */

    ret = cpufreq_set_policy(&new_policy);
    if (ret) {
    dprintk("setting policy failed\n");
    goto err_out_unregister;
    }

    ...

    err_out_unregister:
    spin_lock_irqsave(&cpufreq_driver_lock, flags);
    for_each_cpu_mask(j, policy->cpus)
    cpufreq_cpu_data[j] = NULL;
    spin_unlock_irqrestore(&cpufreq_driver_lock, flags);

    kobject_unregister(&policy->kobj);
    wait_for_completion(&policy->kobj_unregister);

    err_out_driver_exit:
    if (cpufreq_driver->exit)
    cpufreq_driver->exit(policy);

    err_out:
    kfree(policy);


    With the patch above we'll mutex_unlock twice.
    Is that allowed ? It sounds wrong to me.

    Dave

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-01-18 20:12    [W:0.024 / U:91.228 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site