linux-kernel - Re: [PATCH v2] cpufreq: Register with perf domain before

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: <529d967f-9dbc-5b35-546a-428cbb191f0f@arm.com>
Date:   Wed, 18 Jan 2023 09:24:02 +0000
From:   Lukasz Luba <lukasz.luba@....com>
To:     Viresh Kumar <viresh.kumar@...aro.org>,
        Vincent Wang <bhuwz@....com>,
        Vincent Wang <vincentwang3@...ovo.com>
Cc:     rafael@...nel.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] cpufreq: Register with perf domain before

Hi Viresh, Vincent

I'm surprised seeing this thread and thanks that you Viresh have
answered, so it could go through my spam/junk filters.
(I hope when answer to that domain it would change something).

On 1/18/23 08:49, Viresh Kumar wrote:
> On 18-01-23, 12:47, Vincent Wang 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.
> 
> Can you please give detail of the exact code path, for mainline kernel
> ? I am not sure which kworker thread are you talking about here.

Please also tell us your cpufreq governor. The schedutil governor
at mainline can handle those situations and we rebuild the perf domains
here [1].

> 
>> 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.

Viresh, If that's an issue for other governors, than maybe
we should address that. IMO the patch just relies on side-effect
in arch_topology.c update_topology_flags_workfn(). That would be
a workaround and dangerous if someone would change that arch_topology.c
design. Shouldn't we come up with something reliable inside the
cpufreq.c if there is a real issue?
Even now, these two mechanisms:
1. in the schedutil [1]
2. in the update_topology_flags_workfn()
are a bit leaky (in terms of design holes).

Regards,
Lukasz

[1] 
https://elixir.bootlin.com/linux/latest/source/kernel/sched/cpufreq_schedutil.c#L858