linux-kernel - Re: perf usage of arch/arm64/include/asm/cputype.h

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3dbc1f1b-a325-1525-f9f0-8172033438ec@huawei.com>
Date: Wed, 18 Jun 2025 19:51:03 +0800
From: Yicong Yang <yangyicong@...wei.com>
To: Leo Yan <leo.yan@....com>, Mark Rutland <mark.rutland@....com>
CC: <yangyicong@...ilicon.com>, Shameerali Kolothum Thodi
	<shameerali.kolothum.thodi@...wei.com>, James Clark <james.clark@...aro.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, Ali Saidi <alisaidi@...zon.com>, "Leo
 Yan" <leo.yan@...aro.org>, Will Deacon <will@...nel.org>, James Morse
	<james.morse@....com>, Catalin Marinas <catalin.marinas@....com>, yangjinqian
	<yangjinqian1@...wei.com>, Douglas Anderson <dianders@...omium.org>, "Dmitry
 Baryshkov" <dmitry.baryshkov@...aro.org>, Adrian Hunter
	<adrian.hunter@...el.com>, Ian Rogers <irogers@...gle.com>, Jiri Olsa
	<jolsa@...nel.org>, Kan Liang <kan.liang@...ux.intel.com>, Namhyung Kim
	<namhyung@...nel.org>, Linux Kernel Mailing List
	<linux-kernel@...r.kernel.org>
Subject: Re: perf usage of arch/arm64/include/asm/cputype.h

On 2025/6/18 19:24, Leo Yan wrote:
> On Wed, Jun 18, 2025 at 09:52:53AM +0100, Mark Rutland wrote:
> 
> [...]
> 
>>>> Other than that, I think that userspace should just maintain its own
>>>> infrastructure, and only pull in things from kernel sources when there's
>>>> a specific reason to. Otherwise we're just creating busywork.
>>>
>>> I agree with the methodology.
>>>
>>> Since Arnaldo is facing build failure when sync headers between kernel
>>> and perf tool, to avoid long latency, let us split the refactoriing
>>> into separate steps.
>>>
>>> As a first step, I think my previous suggestion is valid, we can create a
>>> header tools/perf/arch/arm64/include/cputype.h with below code:
>>>
>>>   #include "../../../../arch/arm64/include/asm/cputype.h"
>>
>> Directly including the kernel header introduces the very fragility that
>> having a copy was intended to avoid. NAK to that.
> 
> My suggestion is not to include the kernel header, nor to modify the
> copy header. :)
> 
> Instead, I suggested creating a new header within the perf tool (under
> perf's arm64 folder) and then include the copy header in tools:
> 
>   tools/arch/arm64/include/asm/cputype.h
> 

sorry for the misunderstood.:(
in this way we still have the divergency in the long term and as a workaround
this works same if we partly update the tools/arch/arm64/include/asm/cputype.h
with only necessary MIDR updates and keep is_midr_in_range_list() unchanged.

>> I've replied to the same effect Yicong's patch [1,2].
>>
>> If we want to share headers between userspace and kernel, we should
>> refactor those headers such that this is safe by construction.
>>
>> There is no need to update the userspace headers just because the kernel
>> headers have changed, so the simple solution in the short term is to
>> suppress the warning from check-headers.sh.
> 
> Sure, makes sense for me.
> 
> @Arnaldo, as Mark suggested, do you want me to send a patch to remove
> cputype.h checking in check-headers.sh or it is fine to keep the warning
> until finish the header refactoring?
> 
> @Yicong, could you confirm if you proceed to refactor the MIDR? thanks!
> 

please feel free to take this over.

> Just note, I searched tools folder and found kselftest also uses the
> cputype.h header. The refactoring should not break the files below.
> 

they shouldn't affected. I did a kselftest build test with my latest patch
and they were not affected.

thanks.

> $ git grep cputype.h
> perf/check-headers.sh:check arch/arm64/include/asm/cputype.h '-I "^#include [<\"]\(asm/\)*sysreg.h"'
> perf/util/arm-spe.c:#include "../../arch/arm64/include/asm/cputype.h"
> testing/selftests/kvm/arm64/psci_test.c:#include <asm/cputype.h>
> testing/selftests/kvm/lib/arm64/vgic.c:#include <asm/cputype.h>
> 
> Thanks,
> Leo
> 
>> [1] https://lore.kernel.org/linux-arm-kernel/dc5afc5c-060c-8bcb-c3a7-0de49a7455fb@huawei.com/T/#m23dfbea6af559f3765d89b9d8427213588871ffd
>> [2] https://lore.kernel.org/linux-arm-kernel/dc5afc5c-060c-8bcb-c3a7-0de49a7455fb@huawei.com/T/#m6acbfa00002af8ee791266ea86a58f8f994ed710
>>
>> Mark.
>>
>>>
>>>   static bool is_perf_midr_in_range_list(u32 midr,
>>>                                          struct midr_range const *ranges)
>>>   {
>>>           while (ranges->model) {
>>>                   if (midr_is_cpu_model_range(midr, ranges->model,
>>>                                   ranges->rv_min, ranges->rv_max))
>>>                           return true;
>>>                   ranges++;
>>>           }
>>>
>>>           return false;
>>>   }
>>>
>>> Then, once we can generate a dynamic MIDR header file, we can use that
>>> header and define the midr_range structure specifically in the perf.
>>> In the end, perf can avoid to include kernel's cputype.h.
>>>
>>> If no objection, Yicong, do you mind preparing the patch mentioned
>>> above? Thanks!
>>>
>>> Leo
> 
> .
>