Re: PROBLEM: Kernel OOPS and possible system freeze after concurrent writing to cpufreq/scaling_governor (Resend)

["Robert Schöne" <robert.schoene@tu-dresden.de>]

[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]

The patch you suggested did not work, so I introduced a new mutex in the
patch below.

I am not happy with adding just another mutex, but it fixes my problem
of changing governors concurrently.

Robert



This patch fixes a race condition when concurrently writing to cpufreq/scaling_governor


diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index d9fdedd..2ad6b03 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -572,8 +572,15 @@ static ssize_t show_scaling_governor(struct cpufreq_policy *policy, char *buf)
 }
 
 /**
+ * This mutex guarantees, that a concurrent writing to cpuX/scaling_governor
+ * does not run into an OOPS.
+ */
+static DEFINE_MUTEX(cpufreq_store_governor_lock);
+
+/**
  * store_scaling_governor - store policy for the specified CPU
  */
+
 static ssize_t store_scaling_governor(struct cpufreq_policy *policy,
                                        const char *buf, size_t count)
 {
@@ -593,11 +600,15 @@ static ssize_t store_scaling_governor(struct cpufreq_policy *policy,
                                                &new_policy.governor))
                return -EINVAL;
 
+       if (! mutex_trylock(&cpufreq_store_governor_lock))
+               return -EBUSY;
+
        ret = cpufreq_set_policy(policy, &new_policy);
 
        policy->user_policy.policy = policy->policy;
        policy->user_policy.governor = policy->governor;
 
+       mutex_unlock(&cpufreq_store_governor_lock);
        if (ret)
                return ret;
        else



[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6454 bytes --]