linux-kernel - Re: [PATCH v1 1/6] perf header: Replace hardcoded max cpus by MAX_NR

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: <0117fe41-0016-49d7-bc73-1ec682ca8783@linux.ibm.com>
Date: Wed, 28 Jan 2026 13:09:51 +0530
From: Shrikanth Hegde <sshegde@...ux.ibm.com>
To: Swapnil Sapkal <swapnil.sapkal@....com>
Cc: mark.rutland@....com, alexander.shishkin@...ux.intel.com, jolsa@...nel.org,
        adrian.hunter@...el.com, thomas.falcon@...el.com, ashelat@...hat.com,
        yu.c.chen@...el.com, gautham.shenoy@....com, ravi.bangoria@....com,
        linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
        peterz@...radead.org, mingo@...hat.com, acme@...nel.org,
        namhyung@...nel.org, irogers@...gle.com, james.clark@....com
Subject: Re: [PATCH v1 1/6] perf header: Replace hardcoded max cpus by
 MAX_NR_CPUS



On 1/28/26 12:19 AM, Swapnil Sapkal wrote:
> cpumask and cpulist from cpu-domain header have hardcoded max_cpus value
> of 1024. Current systems have more cpus than this value. Replace it with
> MAX_NR_CPUS. Also define a macro to represent domain name length.
> 
> Fixes: d40c68a49f69 ("perf header: Support CPU DOMAIN relation info")
> Reported-by: Shrikanth Hegde <sshegde@...ux.ibm.com>
> Signed-off-by: Swapnil Sapkal <swapnil.sapkal@....com>
> ---
>   tools/perf/util/header.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
> index eefd1cd73b6a..31c3bab1b10a 100644
> --- a/tools/perf/util/header.c
> +++ b/tools/perf/util/header.c
> @@ -76,6 +76,7 @@ static const u64 __perf_magic2    = 0x32454c4946524550ULL;
>   static const u64 __perf_magic2_sw = 0x50455246494c4532ULL;
>   
>   #define PERF_MAGIC	__perf_magic2
> +#define DNAME_LEN	16
>   
>   const char perf_version_string[] = PERF_VERSION;
>   
> @@ -1616,10 +1617,10 @@ static int write_pmu_caps(struct feat_fd *ff,
>   
>   struct cpu_domain_map **build_cpu_domain_map(u32 *schedstat_version, u32 *max_sched_domains, u32 nr)
>   {
> +	char dname[DNAME_LEN], cpumask[MAX_NR_CPUS];
>   	struct domain_info *domain_info;
>   	struct cpu_domain_map **cd_map;
> -	char dname[16], cpumask[256];
> -	char cpulist[1024];
> +	char cpulist[MAX_NR_CPUS];
>   	char *line = NULL;
>   	u32 cpu, domain;
>   	u32 dcount = 0;

Looking at
https://lore.kernel.org/all/20260119175833.340369-3-swapnil.sapkal@amd.com/

There was one more "char cpus[1024]"  in tools/perf/util/util.c.
You may need to fix that too. It is unlikely but, if one has created exclusive
cpusets comprising of only one cpu from a core, maybe you will run out the length.
So better use the MAX_NR_CPUS there as well.