lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 12 May 2010 16:08:37 +0800
From:	Américo Wang <xiyou.wangcong@...il.com>
To:	Andrej Gelenberg <andrej.gelenberg@....edu>
Cc:	linux@...do.de, ashok.raj@...el.com, jacob.shin@....com,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [PATCH] [CPUFREQ] fix race condition in store_scaling_governor

On Tue, May 11, 2010 at 04:20:41PM +0200, Andrej Gelenberg wrote:
>Wrap store_scaling_governor with mutex lock cpufreq_governor_mutex.
>Fix kernel panic if switch scaling governor very fast.
>Bug in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=15948
>
>Signed-off-by: Andrej Gelenberg <andrej.gelenberg@....edu>
>---
> drivers/cpufreq/cpufreq.c |   16 +++++++++++-----
> 1 files changed, 11 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>index 75d293e..6ba42f9 100644
>--- a/drivers/cpufreq/cpufreq.c
>+++ b/drivers/cpufreq/cpufreq.c
>@@ -403,8 +403,6 @@ static int cpufreq_parse_governor(char
>*str_governor, unsigned int *policy,
> 	} else if (cpufreq_driver->target) {
> 		struct cpufreq_governor *t;
>
>-		mutex_lock(&cpufreq_governor_mutex);
>-
> 		t = __find_governor(str_governor);
>
> 		if (t == NULL) {
>@@ -429,8 +427,6 @@ static int cpufreq_parse_governor(char
>*str_governor, unsigned int *policy,
> 			*governor = t;
> 			err = 0;
> 		}
>-
>-		mutex_unlock(&cpufreq_governor_mutex);
> 	}
> out:
> 	return err;
>@@ -521,7 +517,7 @@ static ssize_t show_scaling_governor(struct
>cpufreq_policy *policy, char *buf)
> /**
>  * store_scaling_governor - store policy for the specified CPU
>  */
>-static ssize_t store_scaling_governor(struct cpufreq_policy *policy,
>+static ssize_t _store_scaling_governor(struct cpufreq_policy *policy,
> 					const char *buf, size_t count)
> {
> 	unsigned int ret = -EINVAL;
>@@ -553,6 +549,16 @@ static ssize_t store_scaling_governor(struct
>cpufreq_policy *policy,
> 		return count;
> }
>
>+static ssize_t store_scaling_governor(struct cpufreq_policy *policy,
>+                                        const char *buf, size_t count)
>+{
>+        ssize_t ret;
>+	mutex_lock(&cpufreq_governor_mutex);
>+        ret = _store_scaling_governor(policy, buf, count);
>+	mutex_unlock(&cpufreq_governor_mutex);
>+        return ret;
>+}
>+

Sorry, I don't get it, cpufreq_governor_mutex is used to protect
cpufreq_governor_list. What is the point of moving it up?
Can you explain what the race condition is?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ