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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ