linux-kernel - Re: [PATCH] cpufreq: Send CPUFREQ_CREATE_POLICY notification after the perf domain creation.

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] [day] [month] [year] [list]

Message-ID: <CAJZ5v0iobEEpOY-ww6GqBbKk-MKmyWFSLi8akVUM9fZT7foSUw@mail.gmail.com>
Date:   Tue, 17 Jan 2023 14:30:17 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Vincent Wang <bhuwz@....com>
Cc:     rafael@...nel.org, viresh.kumar@...aro.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Vincent Wang <vincentwang3@...ovo.com>
Subject: Re: [PATCH] cpufreq: Send CPUFREQ_CREATE_POLICY notification after
 the perf domain creation.

On Mon, Jan 16, 2023 at 12:52 AM Vincent Wang <bhuwz@....com> wrote:
>
> From: Vincent Wang <vincentwang3@...ovo.com>
>
> We found the following issue during kernel boot on android phone:
>
> [    1.325272][    T1] cpu cpu0: EM: created perf domain
> [    1.329317][    T1] cpu cpu4: EM: created perf domain
> [    1.337597][   T76] pd_init: no EM found for CPU7
> [    1.350849][    T1] cpu cpu7: EM: created perf domain
>
> pd init for cluster2 is executed in a kworker thread and
> is earlier than the perf domain creation for cluster2.
>
> pd_init() is called from the cpufreq notification of
> CPUFREQ_CREATE_POLICY in cpufreq_online(), which is earlier
> than that cpufreq_driver->register_em() is called.
>
> To avoid this issue, cpufreq notification should be sent after
> the perf domain creation.
>
> Signed-off-by: Vincent Wang <vincentwang3@...ovo.com>
> ---
>  drivers/cpufreq/cpufreq.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 7e56a42750ea..af8836069398 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1430,9 +1430,6 @@ static int cpufreq_online(unsigned int cpu)
>                         policy->max_freq_req = NULL;
>                         goto out_destroy_policy;
>                 }
> -
> -               blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
> -                               CPUFREQ_CREATE_POLICY, policy);
>         }

AFAICS, in some cases, this may cause cpufreq_online() to send
CPUFREQ_REMOVE_POLICY without sending CPUFREQ_CREATE_POLICY which is
generally confusing to its callers.

I'm wondering if you can reorder the EM registration before the
initialization of frequency QoS for the policy?

>
>         if (cpufreq_driver->get && has_target()) {
> @@ -1506,6 +1503,9 @@ static int cpufreq_online(unsigned int cpu)
>                  */
>                 if (cpufreq_driver->register_em)
>                         cpufreq_driver->register_em(policy);
> +
> +               blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
> +                               CPUFREQ_CREATE_POLICY, policy);
>         }
>
>         ret = cpufreq_init_policy(policy);
> --