linux-kernel - Re: [RFC 7/9] cpufreq: governor: support scheduler cpufreq callbacks on remote CPUs

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]

Message-ID: <3331999.EqKcTVSiQr@aspire.rjw.lan>
Date:   Thu, 30 Mar 2017 00:14:30 +0200
From:   "Rafael J. Wysocki" <rjw@...ysocki.net>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        linaro-kernel@...ts.linaro.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>,
        smuckle.linux@...il.com, juri.lelli@....com,
        Morten.Rasmussen@....com, patrick.bellasi@....com,
        eas-dev@...ts.linaro.org
Subject: Re: [RFC 7/9] cpufreq: governor: support scheduler cpufreq callbacks on remote CPUs

On Thursday, March 09, 2017 05:15:17 PM Viresh Kumar wrote:
> From: Steve Muckle <smuckle.linux@...il.com>
> 
> In preparation for the scheduler cpufreq callback happening on remote
> CPUs, add support for this in the legacy (ondemand and conservative)
> governors. The legacy governors make assumptions about the callback
> occurring on the CPU being updated.
> 
> Signed-off-by: Steve Muckle <smuckle.linux@...il.com>
> [ vk: minor updates in commit log ]
> Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
> ---
>  drivers/cpufreq/cpufreq_governor.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
> index 47e24b5384b3..c9e786e7ee1f 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -315,7 +315,7 @@ static void dbs_update_util_handler(struct update_util_data *data, u64 time,
>  
>  	policy_dbs->last_sample_time = time;
>  	policy_dbs->work_in_progress = true;
> -	irq_work_queue(&policy_dbs->irq_work);
> +	irq_work_queue_on(&policy_dbs->irq_work, data->cpu);

I'm totally unconvinced that this is sufficient.

This function carries out lockless computations with the assumption that it
will always run on the CPU being updated.

For instance, how is it prevented from being run on two CPUs in parallel in
the single-CPU policy case if cross-CPU updates are allowed to happen?

Second, is accessing rq_clock(rq) of a remote runqueue a good idea entirely?

Thanks,
Rafael