linux-kernel - Re: [PATCH v5 02/10] perf header: Support CPU DOMAIN relation info

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: <16b0e37d-978b-4991-a16d-425f00e50029@amd.com>
Date: Fri, 23 Jan 2026 20:49:40 +0530
From: Swapnil Sapkal <swapnil.sapkal@....com>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>
CC: <ravi.bangoria@....com>, <yu.c.chen@...el.com>, <mark.rutland@....com>,
	<alexander.shishkin@...ux.intel.com>, <jolsa@...nel.org>,
	<rostedt@...dmis.org>, <vincent.guittot@...aro.org>,
	<adrian.hunter@...el.com>, <kan.liang@...ux.intel.com>,
	<gautham.shenoy@....com>, <kprateek.nayak@....com>, <juri.lelli@...hat.com>,
	<yangjihong@...edance.com>, <void@...ifault.com>, <tj@...nel.org>,
	<ctshao@...gle.com>, <quic_zhonhan@...cinc.com>, <thomas.falcon@...el.com>,
	<blakejones@...gle.com>, <ashelat@...hat.com>, <leo.yan@....com>,
	<dvyukov@...gle.com>, <ak@...ux.intel.com>, <yujie.liu@...el.com>,
	<graham.woodward@....com>, <ben.gainey@....com>, <vineethr@...ux.ibm.com>,
	<tim.c.chen@...ux.intel.com>, <linux@...blig.org>, <santosh.shukla@....com>,
	<sandipan.das@....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 v5 02/10] perf header: Support CPU DOMAIN relation info

Hi Shrikanth,

Thanks for the review.

On 21-01-2026 22:48, Shrikanth Hegde wrote:
> Hi Swapnil.
> 
> 

[...]

>>   }
>> +static struct cpu_domain_map **build_cpu_domain_map(u32 
>> *schedstat_version, u32 *max_sched_domains,
>> +                            u32 nr)
>> +{
>> +    struct domain_info *domain_info;
>> +    struct cpu_domain_map **cd_map;
>> +    char dname[16], cpumask[256];
> 
> You should likely make cpumask and cpulist as NR_CPUS to be
> safe.
> 
> 256 will work till 1024 CPUs no? These days there are systems with
> more CPUs than that.
> 
> Making it NR_CPUS will likely cover all crazy cases/configurations.
> 

This was a miss at my end. This should be NR_CPUS.

--
Thanks and Regards,
Swapnil