linux-kernel - Re: [PATCH 1/1] Cpufreq: Remove fossil comment of cpufreq_set

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, 11 Sep 2013 15:38:25 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Lan Tianyu <tianyu.lan@...el.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] Cpufreq: Remove fossil comment of cpufreq_set_policy

On 11 September 2013 08:58, Lan Tianyu <tianyu.lan@...el.com> wrote:
> From 668e1b6fd94b5c0e56a651b4c60cbbc7a6868b46 Mon Sep 17 00:00:00 2001
> From: Lan Tianyu <tianyu.lan@...el.com>
> Date: Wed, 11 Sep 2013 11:31:15 +0800
> Subject: [PATCH] Cpufreq/governor: Remove fossil comment
>
> cpufreq_set_policy() has been changed to origin __cpufreq_set_policy()
> and policy->lock has been converted to rewrite lock by commit 5a01f2.
> So remove it.
>
> Signed-off-by: Lan Tianyu <tianyu.lan@...el.com>
> ---
>  drivers/cpufreq/cpufreq_userspace.c | 11 -----------
>  1 file changed, 11 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq_userspace.c
> b/drivers/cpufreq/cpufreq_userspace.c
> index 0307809..4dbf1db 100644
> --- a/drivers/cpufreq/cpufreq_userspace.c
> +++ b/drivers/cpufreq/cpufreq_userspace.c
> @@ -38,18 +38,7 @@ static int cpufreq_set(struct cpufreq_policy *policy,
> unsigned int freq)
>         if (!per_cpu(cpu_is_managed, policy->cpu))
>                 goto err;
>
> -       /*
> -        * We're safe from concurrent calls to ->target() here
> -        * as we hold the userspace_mutex lock. If we were calling
> -        * cpufreq_driver_target, a deadlock situation might occur:
> -        * A: cpufreq_set (lock userspace_mutex) ->
> -        *      cpufreq_driver_target(lock policy->lock)
> -        * B: cpufreq_set_policy(lock policy->lock) ->
> -        *      __cpufreq_governor ->
> -        *         cpufreq_governor_userspace (lock userspace_mutex)
> -        */
>         ret = __cpufreq_driver_target(policy, freq, CPUFREQ_RELATION_L);
> -
>   err:
>         mutex_unlock(&userspace_mutex);
>         return ret;

Looks fine:

Acked-by: Viresh Kumar <viresh.kumar@...aro.org>
--
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/