Re: [PATCH] cpufreq: Fix timer/workqueue corruption by protectingreading governor_enabled

[Viresh Kumar]

On 30 December 2013 11:59, Jane Li <jiel@xxxxxxxxxxx> wrote:
> I checked my code, and found I lost following part.
> My local code base is not exactly same as open source, and has included
> this.
>
>
> diff --git a/drivers/cpufreq/cpufreq_governor.c
> b/drivers/cpufreq/cpufreq_governor.c
> index e6be635..c4d0ee6 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -19,6 +19,7 @@
>  #include <linux/export.h>
>  #include <linux/kernel_stat.h>
>  #include <linux/slab.h>
> +#include <linux/cpufreq.h>
>
>  #include "cpufreq_governor.h"

This shouldn't be required as cpufreq_governor.h must be including
cpufreq.h..

> Yes, I test it. After adding cpufreq_governor_lock in gov_queue_work() and
> running same test, there is no debugobjects warning.

But it really can't work at all.. There should be a separate copy of lock
in every file that includes cpufreq.h.. And so this shouldn't have worked.

> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 16d7b4a..185c9f5 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -39,7 +39,7 @@ static struct cpufreq_driver *cpufreq_driver;
>
>  static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
>  static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data_fallback);
>  static DEFINE_RWLOCK(cpufreq_driver_lock);
> -static DEFINE_MUTEX(cpufreq_governor_lock);
> +DEFINE_MUTEX(cpufreq_governor_lock);
>
>  static LIST_HEAD(cpufreq_policy_list);
>
>  #ifdef CONFIG_HOTPLUG_CPU
> diff --git a/drivers/cpufreq/cpufreq_governor.c
> b/drivers/cpufreq/cpufreq_governor.c
> index e6be635..485ee0d 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -22,6 +22,8 @@
>
>  #include "cpufreq_governor.h"
>
> +extern struct mutex cpufreq_governor_lock;
> +

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