linux-kernel - Re: [PATCH] cpufreq: respect the min/max settings from user space

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:	Mon, 6 Oct 2014 10:15:31 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Vince Hsu <vinceh@...dia.com>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Bill Huang <bilhuang@...dia.com>, dgreid@...gle.com,
	olofj@...omium.org
Subject: Re: [PATCH] cpufreq: respect the min/max settings from user space

On 2 October 2014 12:25, Vince Hsu <vinceh@...dia.com> wrote:
> When the user space tries to set scaling_(max|min)_freq through
> sysfs, the cpufreq_set_policy() asks other driver's opinions
> for the max/min frequencies. Some device drivers, like Tegra
> CPU EDP which is not upstreamed yet though, may constrain the
> CPU maximum frequency dynamically because of board design.
> So if the user space access happens and some driver is capping
> the cpu frequency at the same time, the user_policy->(max|min)
> is overridden by the capped value, and that's not expected by
> the user space. And if the user space is not invoked again,
> the CPU will always be capped by the user_policy->(max|min)
> even no drivers limit the CPU frequency any more.
>
> This patch preserves the user specified min/max settings, so that
> every time the cpufreq policy is updated, the new max/min can
> be re-evaluated correctly based on the user's expection and
> the present device drivers' status.
>
> Signed-off-by: Vince Hsu <vinceh@...dia.com>
> ---
> Hi,
>
> I'm not sure if any platform that is supported mainlin might have this
> issue, and this patch is complie tested only.

Why only compiled tested? Why haven't you tested it on tegra?

>  drivers/cpufreq/cpufreq.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 24bf76fba141..c007cf2a3d2a 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -524,7 +524,7 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
>  static ssize_t store_##file_name                                       \
>  (struct cpufreq_policy *policy, const char *buf, size_t count)         \
>  {                                                                      \
> -       int ret;                                                        \
> +       int ret, temp;                                          \
>         struct cpufreq_policy new_policy;                               \
>                                                                         \
>         ret = cpufreq_get_policy(&new_policy, policy->cpu);             \
> @@ -535,8 +535,10 @@ static ssize_t store_##file_name                                   \
>         if (ret != 1)                                                   \
>                 return -EINVAL;                                         \
>                                                                         \
> +       temp = new_policy.object;                                       \
>         ret = cpufreq_set_policy(policy, &new_policy);          \
> -       policy->user_policy.object = policy->object;                    \
> +       if (!ret)                                                       \
> +               policy->user_policy.object = temp;                      \
>                                                                         \
>         return ret ? ret : count;                                       \
>  }

Looks fine otherwise.

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/