From nobody Mon Jun 8 05:24:57 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 04CFD3793AA; Sat, 6 Jun 2026 20:06:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780776378; cv=none; b=MXBpt8CdH02e0MK5c9XabHM4rR7N/UCkyywSPbvU/BLAmXck0xUvNsKOWQ5+43CYwdq4f9kNtbj4ZnCfSe0PjLri36UnAuH+JwONgiJe1NkGlMTGVcXrQS1q96wu4Vz2UkKA7zX4eBcyFOuxKBx+fqIQgzL4RaQaJYu0uHjfN74= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780776378; c=relaxed/simple; bh=x/qyZQUq8mGXqgJoXciDpBAOG9Wt3kK2/xGqd69QYvM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MkZt7JyhM/e9SQ9oe7ItmvYEegOiHV8+8HnpiyQGF+JMhs5Qf+BmBTsV86BenUKNDtAH6/MKdxwV0ZiB5W3WgX81gEKWStqNxh+eqfo1Gu5DE4u0ZrR4ghZRWpW1/wTjNgXCaMGtIgusIF5WELmH/EuJvBi0exhlwFUQ/CRw7b0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UDeOktvj; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UDeOktvj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 713491F00898; Sat, 6 Jun 2026 20:06:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780776377; bh=zFT7NR1V7cGZRAKQdOM3vBh2LFdUb7iUOlXifB7O/UM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=UDeOktvjdaLAqj2n212uyUN18rs4T1SaWGkT3VRQnxX5Q4KbBOyF5cMkCUsKh7t+C ln8Gzm6A/DbLHfa1WcV8p5Q4ErevKiJ2Ox+QHZM/YPvRnISlx5DVF+GzWqkDJNX4Qh mSKJTrC1d/KVH4HhYnV10eAdCS5VgvbZrIz4Zz/V9lU+NEKh2K0Wa5u1ZQhQfbM/a6 3f5lg03kOMK0sOYdSR8sNYMnmtaE1Ra13VLKuCM5MPMhIpsEe0jMY6rDWDbMPyqXRU eaQ0wd7ScNnE6Kq1R7ZcHAmAsWznVbx14lkarw9XMLQW+8mpNFydMppxhMB5P8cpIx r+Y+12xCSy31g== From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Ingo Molnar , Thomas Gleixner , James Clark , Jiri Olsa , Ian Rogers , Adrian Hunter , Clark Williams , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Arnaldo Carvalho de Melo , sashiko-bot , Alexey Budankov , "Claude Opus 4.6" Subject: [PATCH 1/7] perf mmap: Fix NULL deref in aio cleanup on alloc failure Date: Sat, 6 Jun 2026 17:05:53 -0300 Message-ID: <20260606200601.1861227-2-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260606200601.1861227-1-acme@kernel.org> References: <20260606200601.1861227-1-acme@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnaldo Carvalho de Melo perf_mmap__aio_mmap() sets map->aio.nr_cblocks before allocating the data array. If calloc() for aiocb or cblocks fails before the data array is allocated, the return -1 path leads to perf_mmap__aio_munmap() which loops nr_cblocks times calling perf_mmap__aio_free(). Both versions of perf_mmap__aio_free() (NUMA and non-NUMA) dereference map->aio.data[idx] without checking if data is NULL, causing a NULL pointer dereference. Add NULL checks for map->aio.data at the top of both perf_mmap__aio_free() variants so the cleanup path is safe when allocation fails partway through perf_mmap__aio_mmap(). Fixes: d3d1af6f011a553a ("perf record: Enable asynchronous trace writing") Reported-by: sashiko-bot Cc: Alexey Budankov Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/mmap.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c index 4404a99eee45f9c3..d64aec6c7c843e81 100644 --- a/tools/perf/util/mmap.c +++ b/tools/perf/util/mmap.c @@ -89,10 +89,10 @@ static int perf_mmap__aio_alloc(struct mmap *map, int i= dx) =20 static void perf_mmap__aio_free(struct mmap *map, int idx) { - if (map->aio.data[idx]) { - munmap(map->aio.data[idx], mmap__mmap_len(map)); - map->aio.data[idx] =3D NULL; - } + if (!map->aio.data || !map->aio.data[idx]) + return; + munmap(map->aio.data[idx], mmap__mmap_len(map)); + map->aio.data[idx] =3D NULL; } =20 static int perf_mmap__aio_bind(struct mmap *map, int idx, struct perf_cpu = cpu, int affinity) @@ -141,6 +141,8 @@ static int perf_mmap__aio_alloc(struct mmap *map, int i= dx) =20 static void perf_mmap__aio_free(struct mmap *map, int idx) { + if (!map->aio.data) + return; zfree(&(map->aio.data[idx])); } =20 --=20 2.54.0 From nobody Mon Jun 8 05:24:57 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 14AB43BA249; Sat, 6 Jun 2026 20:06:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780776384; cv=none; b=JzcLxIgBIJVT1+cI1gNa4YlgQDmutaUCcG+E/KNm7Pi1eSl4mhK8Q+zWGSO6maPuNHb5ot5hCPlLPjqiOR7D/b0pgjev69H5eRWV1ZyovHAfxPqlpYQawT5gzjYyrmCnfJ+LJGT31YnkPeeSi9CYE1FvrFjQEuxGLGxRv+md+rg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780776384; c=relaxed/simple; bh=4MweEw1Ex4UoFL/cN03InEtalcZOsuLoLYbhKDZvt9k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=VXXiRSBNDax2sRTXIN1o54YS3dw/QoYIWHzjWgxQRlHLo/+D49fJ23hDt12WAi1Ez3KCOT6Y8LF4WlFnkeVkWsRUr2xIGb+cqOhrF8ZiyiuZCbXvnI5uuQA+dHwWfWXJg94Alnbllqyf4Mpm8b3OkxwKfLIwKfHRtm6TYQcAxyA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jqtWXhlk; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jqtWXhlk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 322F21F00893; Sat, 6 Jun 2026 20:06:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780776382; bh=qk3DLbX3tUmGMauFpT8erZ5UhtOZfYQSKysDwJfeVK0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=jqtWXhlko7N2jbUajW9D7T/Q/5D6EzjfoOFX/iNvxI1ijeBmD2OQZa751qn+P8Jfe Z8dAaYwLTW3ocM+0+eZ1roYktAK76jsPtElv2Ri6+jqXJOMpr991QZ6mh09DbcEdrS wAgmGOldk7z6DPK9K7Wk0zJAXSH2bYQrGBOOCFasoUUATga4LCkj7sUB+lH3NEDORH BEEqZBBmEDUKt/TUHGVP5stFVv4CqLy0KpCt7UDjY48wG53paQnUechuuexwXpsP2M b0KYcS4x8xPIfXmvHfe8+i7CzKsbEvHsPGg1Q6nSdt200zerDqkQVQuvAP92LdRcuU AaWT+MBJAc5EA== From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Ingo Molnar , Thomas Gleixner , James Clark , Jiri Olsa , Ian Rogers , Adrian Hunter , Clark Williams , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Arnaldo Carvalho de Melo , sashiko-bot , "Claude Opus 4.6" Subject: [PATCH 2/7] perf stat: Introduce perf_env__get_cpu_topology() to guard NULL env->cpu Date: Sat, 6 Jun 2026 17:05:54 -0300 Message-ID: <20260606200601.1861227-3-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260606200601.1861227-1-acme@kernel.org> References: <20260606200601.1861227-1-acme@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Arnaldo Carvalho de Melo process_cpu_topology() in header.c frees env->cpu on old-format perf.data files that predate topology information, but leaves nr_cpus_avail set. The six perf_env__get_*_aggr_by_cpu() functions in builtin-stat.c pass the bounds check but dereference a NULL env->cpu pointer, crashing on old recordings. Introduce perf_env__get_cpu_topology() as a safe accessor that validates env->cpu, cpu.cpu >=3D 0, and cpu.cpu < nr_cpus_avail in one place, returning a struct cpu_topology_map pointer or NULL. Convert all six topology aggregation callbacks to use it. Fixes: 88031a0de7d68d13 ("perf stat: Switch to cpu version of cpu_map__get(= )") Reported-by: sashiko-bot Cc: Ian Rogers Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/builtin-stat.c | 51 +++++++++++++++++++++------------------ tools/perf/util/env.h | 14 +++++++++++ 2 files changed, 42 insertions(+), 23 deletions(-) diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c index 9a045811c4197ccd..a04466ea3b0a0657 100644 --- a/tools/perf/builtin-stat.c +++ b/tools/perf/builtin-stat.c @@ -1637,10 +1637,10 @@ static struct aggr_cpu_id perf_env__get_socket_aggr= _by_cpu(struct perf_cpu cpu, { struct perf_env *env =3D data; struct aggr_cpu_id id =3D aggr_cpu_id__empty(); + struct cpu_topology_map *topo =3D perf_env__get_cpu_topology(env, cpu); =20 - /* env->cpu[] has env->nr_cpus_avail entries; reject untrusted indices */ - if (cpu.cpu >=3D 0 && cpu.cpu < env->nr_cpus_avail) - id.socket =3D env->cpu[cpu.cpu].socket_id; + if (topo) + id.socket =3D topo->socket_id; =20 return id; } @@ -1649,15 +1649,16 @@ static struct aggr_cpu_id perf_env__get_die_aggr_by= _cpu(struct perf_cpu cpu, voi { struct perf_env *env =3D data; struct aggr_cpu_id id =3D aggr_cpu_id__empty(); + struct cpu_topology_map *topo =3D perf_env__get_cpu_topology(env, cpu); =20 - if (cpu.cpu >=3D 0 && cpu.cpu < env->nr_cpus_avail) { + if (topo) { /* * die_id is relative to socket, so start * with the socket ID and then add die to * make a unique ID. */ - id.socket =3D env->cpu[cpu.cpu].socket_id; - id.die =3D env->cpu[cpu.cpu].die_id; + id.socket =3D topo->socket_id; + id.die =3D topo->die_id; } =20 return id; @@ -1705,12 +1706,13 @@ static struct aggr_cpu_id perf_env__get_cache_aggr_= by_cpu(struct perf_cpu cpu, { struct perf_env *env =3D data; struct aggr_cpu_id id =3D aggr_cpu_id__empty(); + struct cpu_topology_map *topo =3D perf_env__get_cpu_topology(env, cpu); =20 - if (cpu.cpu >=3D 0 && cpu.cpu < env->nr_cpus_avail) { + if (topo) { u32 cache_level =3D (perf_stat.aggr_level) ?: stat_config.aggr_level; =20 - id.socket =3D env->cpu[cpu.cpu].socket_id; - id.die =3D env->cpu[cpu.cpu].die_id; + id.socket =3D topo->socket_id; + id.die =3D topo->die_id; perf_env__get_cache_id_for_cpu(cpu, env, cache_level, &id); } =20 @@ -1722,11 +1724,12 @@ static struct aggr_cpu_id perf_env__get_cluster_agg= r_by_cpu(struct perf_cpu cpu, { struct perf_env *env =3D data; struct aggr_cpu_id id =3D aggr_cpu_id__empty(); + struct cpu_topology_map *topo =3D perf_env__get_cpu_topology(env, cpu); =20 - if (cpu.cpu >=3D 0 && cpu.cpu < env->nr_cpus_avail) { - id.socket =3D env->cpu[cpu.cpu].socket_id; - id.die =3D env->cpu[cpu.cpu].die_id; - id.cluster =3D env->cpu[cpu.cpu].cluster_id; + if (topo) { + id.socket =3D topo->socket_id; + id.die =3D topo->die_id; + id.cluster =3D topo->cluster_id; } =20 return id; @@ -1736,16 +1739,17 @@ static struct aggr_cpu_id perf_env__get_core_aggr_b= y_cpu(struct perf_cpu cpu, vo { struct perf_env *env =3D data; struct aggr_cpu_id id =3D aggr_cpu_id__empty(); + struct cpu_topology_map *topo =3D perf_env__get_cpu_topology(env, cpu); =20 - if (cpu.cpu >=3D 0 && cpu.cpu < env->nr_cpus_avail) { + if (topo) { /* * core_id is relative to socket, die and cluster, we need a * global id. So we set socket, die id, cluster id and core id. */ - id.socket =3D env->cpu[cpu.cpu].socket_id; - id.die =3D env->cpu[cpu.cpu].die_id; - id.cluster =3D env->cpu[cpu.cpu].cluster_id; - id.core =3D env->cpu[cpu.cpu].core_id; + id.socket =3D topo->socket_id; + id.die =3D topo->die_id; + id.cluster =3D topo->cluster_id; + id.core =3D topo->core_id; } =20 return id; @@ -1755,18 +1759,19 @@ static struct aggr_cpu_id perf_env__get_cpu_aggr_by= _cpu(struct perf_cpu cpu, voi { struct perf_env *env =3D data; struct aggr_cpu_id id =3D aggr_cpu_id__empty(); + struct cpu_topology_map *topo =3D perf_env__get_cpu_topology(env, cpu); =20 - if (cpu.cpu >=3D 0 && cpu.cpu < env->nr_cpus_avail) { + if (topo) { /* * core_id is relative to socket and die, * we need a global id. So we set * socket, die id and core id */ - id.socket =3D env->cpu[cpu.cpu].socket_id; - id.die =3D env->cpu[cpu.cpu].die_id; - id.core =3D env->cpu[cpu.cpu].core_id; - id.cpu =3D cpu; + id.socket =3D topo->socket_id; + id.die =3D topo->die_id; + id.core =3D topo->core_id; } + id.cpu =3D cpu; =20 return id; } diff --git a/tools/perf/util/env.h b/tools/perf/util/env.h index 7621d1f73b83a341..7acca39b42ff3531 100644 --- a/tools/perf/util/env.h +++ b/tools/perf/util/env.h @@ -187,6 +187,20 @@ const char *perf_env__pmu_mappings(struct perf_env *en= v); =20 int perf_env__read_cpu_topology_map(struct perf_env *env); =20 +/* + * Safe accessor for env->cpu[] topology array. env->cpu can be NULL when + * reading old-format perf.data that predates topology information =E2=80= =94 + * process_cpu_topology() in header.c frees it while nr_cpus_avail remains + * set, so callers must not index env->cpu[] without this check. + */ +static inline struct cpu_topology_map * +perf_env__get_cpu_topology(struct perf_env *env, struct perf_cpu cpu) +{ + if (env->cpu && cpu.cpu >=3D 0 && cpu.cpu < env->nr_cpus_avail) + return &env->cpu[cpu.cpu]; + return NULL; +} + void cpu_cache_level__free(struct cpu_cache_level *cache); =20 uint16_t perf_env__e_machine_nocache(struct perf_env *env, uint32_t *e_fla= gs); --=20 2.54.0 From nobody Mon Jun 8 05:24:57 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 448A938A715; Sat, 6 Jun 2026 20:06:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780776390; cv=none; b=WHlKu7Wi0cebgr3UDqZRX2WNgiYLLy9/Vf3elDUhsX9hmca7QgjolPFGPZjCcRJaUemKgVqDy0RH7tpqbtMEkdGNTnOpWX9zEprLttsb99FVyccUxtU/Nz+iwtFH/J8SoOq2EB6nw6L0YpaLmcFnx2dBikdZ7bNWzzTfvhgL97k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780776390; c=relaxed/simple; bh=cygiRNJeWqRLT+jF20O19SCQdbQVytNO4NvwaK+vi0s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nWCrc5nZLwsn6fDO+xCVI5Bi+GGY62P21I5qurYRb+Y08YsQ5LpB9vSVexRFdbUwx4R+xZbYXAijHuDPr4ygyP5lPnvLkQEME4op7x3dDTEQNZ5H7GI/Ima38I4GLVvwDyurSDcRSdDrQWyuRoUqNyusucufFwH9sM9Flu3/WUo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RzPxkUyj; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RzPxkUyj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4DBF91F00898; Sat, 6 Jun 2026 20:06:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780776388; bh=KOL3QUGILJlAiqmTRGM1oKLgGF3YQH/5gbajDmTJRTw=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=RzPxkUyjykMGoz/HKhpJ4Us6xd9gXVURrrIhWnr1TXL38zc18MztQRSpxlXD0PA26 hUtpNIjNOOvQWSjaJrZ49/mJQecyTCXO2J9UgUwueD9gGFxwARZ2Q5bhFw/X0k8Yrk Q7WFllu4dJQUjV7X790AWUyd5N1FI2uTKxweFu5/yzcYFYCIx1qaogHhvUVgiO721z 7TLoZNLPIEWOxqg+2wY6oVbnsGcXvRocEv37g9JoGmEpky6QWttJe8AoSzp0OetVzC Rlc4TBvXKq61w/B58PoGVLXdMbnHVxaTFHoQfoUhW3jGbYxSb0keYN4CtlnUo+oyF2 Spdt0XTehwjMg== From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Ingo Molnar , Thomas Gleixner , James Clark , Jiri Olsa , Ian Rogers , Adrian Hunter , Clark Williams , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Arnaldo Carvalho de Melo , sashiko-bot , "Claude Opus 4.6" Subject: [PATCH 3/7] perf c2c: Fix use-after-free in he__get_c2c_hists() error path Date: Sat, 6 Jun 2026 17:05:55 -0300 Message-ID: <20260606200601.1861227-4-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260606200601.1861227-1-acme@kernel.org> References: <20260606200601.1861227-1-acme@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnaldo Carvalho de Melo he__get_c2c_hists() assigns c2c_he->hists before calling c2c_hists__init(). If init fails, the error path calls free(hists) but leaves c2c_he->hists pointing to freed memory. On teardown, c2c_he_free() finds the non-NULL pointer and calls hists__delete_entries() on it, causing a use-after-free. Set c2c_he->hists to NULL before freeing so teardown skips the already-freed allocation. Fixes: b2252ae67b687d2b ("perf c2c report: Decode c2c_stats for hist entrie= s") Reported-by: sashiko-bot Cc: Jiri Olsa Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/builtin-c2c.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c index cfc1ebe8c0af74dc..e205f58b2f3d3786 100644 --- a/tools/perf/builtin-c2c.c +++ b/tools/perf/builtin-c2c.c @@ -225,6 +225,7 @@ he__get_c2c_hists(struct hist_entry *he, =20 ret =3D c2c_hists__init(hists, sort, nr_header_lines, env); if (ret) { + c2c_he->hists =3D NULL; free(hists); return NULL; } --=20 2.54.0 From nobody Mon Jun 8 05:24:57 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D634237C913; Sat, 6 Jun 2026 20:06:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780776395; cv=none; b=VUJwNlBm+NucCbXKbCwuND3SGA8UL77z+TlE8Lag5YowBY+kzZGA2Xqz+74dJhJA7t+Qh5i0hKE2BsKicLKSxJGEK1zfr47cHSbUhHFMBlVzmo5sudadVMo7lL0qqs/RO6034Bnceic/Ow8LDhu3BO1WPaZHDD4wdETBwjhh+fc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780776395; c=relaxed/simple; bh=P5hxQtzLLRCe9d9PCH2wSslvM0G7WmFGcbXq+aUnvoo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IgyU3FcFSyuSrE41+8DJlgYVSvMdeMQVadwZY8Ly673pfauKsqPL4jRl/yIDnHIsOy8oJnpOZ+l41L6oSifadC2JwfQ6580YJ8IrjLpS/MOpwO2c9mFcy5Fx5GPE+dQcKaklmENGWEAVsiu8phCDwCN9rSM4jDN1+qlk3R8yrIo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZVb1Wg3J; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZVb1Wg3J" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70B701F00893; Sat, 6 Jun 2026 20:06:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780776394; bh=n5Pt3mJ/skAzMgF/rZiFavZruhwhV9/q/P/HCw6wU2s=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=ZVb1Wg3JvnlgoYqwV57rs9lCs87vpoocp8znot4suapp8mCq4jZSt1OqJ8emFZ0hI Krn7AS9nsRe0NhXeFqO3pvBk0q0t8cnBtGW22Io/Nb7Mol6SnAE+pwzI6dUb4FggyF MXd1sjyJhAvUsDTJMFTa+GKSVQI4hqDuwqW/CJGXvTyCmBO8ZU5MOgbLOneDtD5aLv QUw29n1XjHRWeP7sOjyAJBwRq6zGpSEh99J+Aq6s4VAFyZmEpI0YQBG2F1byHqi+b7 oeScrn07CKSJz7laUBBJYS/vrGc1B92jrwWNDmTCPB2oB6hmiCz8i9mUhcq7ae9kak FcxisEBjIfVmg== From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Ingo Molnar , Thomas Gleixner , James Clark , Jiri Olsa , Ian Rogers , Adrian Hunter , Clark Williams , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Arnaldo Carvalho de Melo , sashiko-bot , Stanislav Fomichev , "Claude Opus 4.6" Subject: [PATCH 4/7] perf timechart: Fix cpu2y() OOB read on untrusted CPU index Date: Sat, 6 Jun 2026 17:05:56 -0300 Message-ID: <20260606200601.1861227-5-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260606200601.1861227-1-acme@kernel.org> References: <20260606200601.1861227-1-acme@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnaldo Carvalho de Melo cpu2y() indexes topology_map[cpu] without bounds checking. The array is allocated with nr_cpus entries (from env->nr_cpus_online), but callers pass sample CPU values from perf.data which can exceed that size with cross-machine recordings. Track the topology_map allocation size and bounds-check the CPU argument in cpu2y() before indexing. Out-of-bounds CPUs fall back to the identity mapping (cpu2slot(cpu)), which is the same behavior as when no topology is available. Fixes: c507999790438cde ("perf timechart: Add support for topology") Reported-by: sashiko-bot Cc: Stanislav Fomichev Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/svghelper.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/tools/perf/util/svghelper.c b/tools/perf/util/svghelper.c index e360e7736c7ba65b..826bd2577344b20f 100644 --- a/tools/perf/util/svghelper.c +++ b/tools/perf/util/svghelper.c @@ -47,13 +47,13 @@ static double cpu2slot(int cpu) } =20 static int *topology_map; +static int topology_map_size; =20 static double cpu2y(int cpu) { - if (topology_map) + if (topology_map && cpu >=3D 0 && cpu < topology_map_size) return cpu2slot(topology_map[cpu]) * SLOT_MULT; - else - return cpu2slot(cpu) * SLOT_MULT; + return cpu2slot(cpu) * SLOT_MULT; } =20 static double time2pixels(u64 __time) @@ -736,7 +736,8 @@ static int str_to_bitmap(char *s, cpumask_t *b, int nr_= cpus) return -1; =20 perf_cpu_map__for_each_cpu(cpu, idx, map) { - if (cpu.cpu >=3D nr_cpus) { + /* perf_cpu_map__new("") returns cpu.cpu =3D=3D -1 */ + if (cpu.cpu < 0 || cpu.cpu >=3D nr_cpus) { ret =3D -1; break; } @@ -794,6 +795,7 @@ int svg_build_topology_map(struct perf_env *env) fprintf(stderr, "topology: no memory\n"); goto exit; } + topology_map_size =3D nr_cpus; =20 for (i =3D 0; i < nr_cpus; i++) topology_map[i] =3D -1; --=20 2.54.0 From nobody Mon Jun 8 05:24:57 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3C427155757; Sat, 6 Jun 2026 20:06:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780776401; cv=none; b=qwbkWFbV1jgzWUuYci2gNiF+YayCeb33F73qxjgoHwlWQVAErUzgHIxdkGxFKyXEG978GiflHJjGYuETOcdH8ORDegw0OMRAUF54cI/zH4WH5cFJjL57caL9dRDo6091gO2CIthDtRhuPblIaP8rC39vW2HIMOsVRntmS5H95G0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780776401; c=relaxed/simple; bh=MgPFe1riTYxByXU+9o65XAXLNS6j6GrUt3UbKk1GOKM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Aw839leHWRtHBiUHcILurd3zbkiICShhDgRlTvV4pjARfms3143Ny0dtuoJCDOXPTgxFTTYUIQz1+U+4fZL3DVWlRt7K2CzkNRh7k2HhN0NhqKWI9CyfS3b/CzPeqouF8pEuls4kUP0g6lqQjCxj6EGr4nQp1SJ9S2l1m6hHuIE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lL525oa5; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lL525oa5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 301131F00898; Sat, 6 Jun 2026 20:06:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780776400; bh=hbST67JSXpzQHfuHrk5vsTjP587tEd8zXcSCma4RepY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=lL525oa5/pC/BK2ihGymAgP76BE0R3vrApPgGBC9c9FQxZrGKNoqEpq7bQliPLdnZ qp9SX5ZIKfLFlxLVmRXJem138+erED6rvyW2dTukFvBHUoz+SDe5OxjyR4MkPtOkGp Kz69TV91h9FlZUGpQxSOTI6leFc5c29JEEYe1gAUZbTSDMHoGJpDfzXUXDZzrG8oYS BkmYGLVDHqEOcyvvrqJ3DUE38l9mt5JhngxENs974BLVvt/bFF3aFC2nsAMBXoa3D/ E6/oJGk058zVX2UtpKdfciANQuwxuO4VExDU/el/UII70kzBD4aznYzdryHdCRto0m 5znpJNmR+AfPg== From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Ingo Molnar , Thomas Gleixner , James Clark , Jiri Olsa , Ian Rogers , Adrian Hunter , Clark Williams , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Arnaldo Carvalho de Melo , sashiko-bot , "Claude Opus 4.6" Subject: [PATCH 5/7] perf tools: Fix int16_t truncation of max_cpu_num in set_max_cpu_num() Date: Sat, 6 Jun 2026 17:05:57 -0300 Message-ID: <20260606200601.1861227-6-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260606200601.1861227-1-acme@kernel.org> References: <20260606200601.1861227-1-acme@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Arnaldo Carvalho de Melo set_max_cpu_num() assigns the sysfs "possible" CPU count to max_cpu_num.cpu which is int16_t (struct perf_cpu). On systems with >32767 possible CPUs the value silently truncates, potentially wrapping negative. This causes cpunode_map to be underallocated and subsequent cpu__get_node() calls to read out of bounds. The matching check for max_present_cpu_num was added by commit c760174401f6 ("perf cpumap: Reduce cpu size from int to int16_t") but max_cpu_num was missed. Add the same INT16_MAX guard. Fixes: c760174401f605cf ("perf cpumap: Reduce cpu size from int to int16_t") Reported-by: sashiko-bot Cc: Ian Rogers Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/cpumap.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c index d3432622b2adc994..21fa781b03cc7409 100644 --- a/tools/perf/util/cpumap.c +++ b/tools/perf/util/cpumap.c @@ -494,6 +494,16 @@ static void set_max_cpu_num(void) if (ret) goto out; =20 + /* + * struct perf_cpu.cpu is int16_t (libperf ABI) =E2=80=94 clamp to avoid + * truncation to negative. See tools/lib/perf/TODO for the ABI + * widening plan. + */ + if (max > INT16_MAX) { + pr_warning("WARNING: max possible cpus %d exceeds int16_t, clamping to %= d\n", + max, INT16_MAX); + max =3D INT16_MAX; + } max_cpu_num.cpu =3D max; =20 /* get the highest present cpu number for a sparse allocation */ @@ -506,11 +516,12 @@ static void set_max_cpu_num(void) ret =3D get_max_num(path, &max); =20 if (!ret && max > INT16_MAX) { - pr_err("Read out of bounds max cpus of %d\n", max); - ret =3D -1; + pr_warning("WARNING: max present cpus %d exceeds int16_t, clamping to %d= \n", + max, INT16_MAX); + max =3D INT16_MAX; } if (!ret) - max_present_cpu_num.cpu =3D (int16_t)max; + max_present_cpu_num.cpu =3D max; out: if (ret) pr_err("Failed to read max cpus, using default of %d\n", max_cpu_num.cpu= ); @@ -647,7 +658,9 @@ int cpu__setup_cpunode_map(void) while ((dent2 =3D readdir(dir2)) !=3D NULL) { if (dent2->d_type !=3D DT_LNK || sscanf(dent2->d_name, "cpu%u", &cpu) <= 1) continue; - cpunode_map[cpu] =3D mem; + /* cpunode_map allocated for max_cpu_num entries */ + if (cpu < (unsigned int)max_cpu_num.cpu) + cpunode_map[cpu] =3D mem; } closedir(dir2); } --=20 2.54.0 From nobody Mon Jun 8 05:24:57 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 505AF3AA507; Sat, 6 Jun 2026 20:06:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780776406; cv=none; b=bLs2XOUp+Fvy8y3ZS7Mm9n8E05BBRbPE8Z8EYzA88UzG+y4F9utkfBEonhByg9WMM5EkQysKUByPIgC2a9Pv2F8jPFCzWcb/3O6JGSyrZ9AqCEI3YYKE4G84P8vw2m97azPjTOstVaDNwRJpt8tgzKUowfVT2u70ft0UVokvgSo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780776406; c=relaxed/simple; bh=tpRn58mPXbibn/1mD53zsa5k6gm4YmIkOr3rpaeI80s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=u2U1NYUhD0Rctxdubww+kSi4/ak9jfgi53tnMHLwmKM0y80B+/XHsaAc9ADH70KG/XH3tx76k7IqinYHn24B1wk/QmCAVs4pT1VZrNe6JK/3wJ6f8m2JAMu1Td0HINM03M/xh2xA1oDOtoRTho92SBr4Wznwy0swhPhirY7vc2s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hWjNa9yW; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hWjNa9yW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 770BB1F00893; Sat, 6 Jun 2026 20:06:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780776405; bh=1tjL0WkxtgQSVt50jRLm7IWs5CaKopZAj1RIXm99+yA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=hWjNa9yWYpkKJgT5e3ENYpNpeOTHQBZ1KVAhT9hXoi32K6s2BF2AuaBxHw/UKclmP ZerGxcxk/6MNjmDSCD845bkPRIQFScBD6LRNExJJQhkx3tLAipd5zEMeLf4J6vQzqU vZ5Ym8KfYU9ZA7hBJpL2WOHS3iTSTGK8fdHkQmlVmGL+w2hA/Q12u6LXsHgYRd503f zatHo65AAe4/D/dF5/l+IaffiZYxo8yKiosRF68oQbR7yVer7PsyQlIwjP10jDamnR YaUO87agaWCJ7KqSvMiQLuGP5Vx5NFRphB/AgFGIee3FazF7bPWkTz11RNE4Z/pJlQ fD4n7R7zAw7zw== From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Ingo Molnar , Thomas Gleixner , James Clark , Jiri Olsa , Ian Rogers , Adrian Hunter , Clark Williams , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Arnaldo Carvalho de Melo , sashiko-bot , "Claude Opus 4.6" Subject: [PATCH 6/7] perf sched: Free callchain nodes in idle thread cleanup Date: Sat, 6 Jun 2026 17:05:58 -0300 Message-ID: <20260606200601.1861227-7-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260606200601.1861227-1-acme@kernel.org> References: <20260606200601.1861227-1-acme@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnaldo Carvalho de Melo free_idle_threads() relies on the thread priv destructor (free()) to clean up idle_thread_runtime structs. But free() doesn't walk the callchain_cursor linked list or the callchain_root tree allocated by callchain_cursor__copy() and callchain_append() during --idle-hist processing. Every idle thread with callchain data leaks these nodes. Introduce callchain_cursor_cleanup() to free the cursor's linked list of callchain_cursor_node entries, and call it together with free_callchain() in free_idle_threads() before thread__put(). Fixes: 225b24f569980ac9 ("perf sched timehist: Save callchain when entering= idle") Reported-by: sashiko-bot Cc: Namhyung Kim Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/builtin-sched.c | 5 ++++- tools/perf/util/callchain.c | 15 +++++++++++++++ tools/perf/util/callchain.h | 1 + 3 files changed, 20 insertions(+), 1 deletion(-) diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c index b7ccdc6a985d1c7b..1ff01f03d2ad1ad3 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -2500,8 +2500,11 @@ static void free_idle_threads(void) struct idle_thread_runtime *itr; =20 itr =3D thread__priv(idle); - if (itr) + if (itr) { thread__put(itr->last_thread); + free_callchain(&itr->callchain); + callchain_cursor_cleanup(&itr->cursor); + } =20 thread__put(idle); } diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c index 8981ae879ebb887c..31c675cbab63187b 100644 --- a/tools/perf/util/callchain.c +++ b/tools/perf/util/callchain.c @@ -1578,6 +1578,21 @@ void free_callchain(struct callchain_root *root) free_callchain_node(&root->node); } =20 +void callchain_cursor_cleanup(struct callchain_cursor *cursor) +{ + struct callchain_cursor_node *node, *next; + + callchain_cursor_reset(cursor); + + for (node =3D cursor->first; node; node =3D next) { + next =3D node->next; + free(node); + } + cursor->first =3D NULL; + cursor->last =3D &cursor->first; + cursor->curr =3D NULL; +} + static u64 decay_callchain_node(struct callchain_node *node) { struct callchain_node *child; diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h index 0eb5d7a1a41d81e1..8b1e405d1cdf4660 100644 --- a/tools/perf/util/callchain.h +++ b/tools/perf/util/callchain.h @@ -286,6 +286,7 @@ int callchain_list_counts__printf_value(struct callchai= n_list *clist, FILE *fp, char *bf, int bfsize); =20 void free_callchain(struct callchain_root *root); +void callchain_cursor_cleanup(struct callchain_cursor *cursor); void decay_callchain(struct callchain_root *root); int callchain_node__make_parent_list(struct callchain_node *node); =20 --=20 2.54.0 From nobody Mon Jun 8 05:24:57 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 754763AA507; Sat, 6 Jun 2026 20:06:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780776411; cv=none; b=kpqllLyvUnQygLmVlU3CUt51be6In2NCyvtDNU/CXwuHZDLNmWPjWlkGkzLsFXZW6rImCmuVy/WG1USgNz3JJGXK7NbpfyWBUqSMZvrf/GyEBf6eL/jZLMJRr0y5D4+4muy2m2+5f7nIuqIOOKloPwEOjT+QG8dwR/TMXyp/P/c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780776411; c=relaxed/simple; bh=otMPZBy/m/mdkpzCRHNeN4v5A2g2PmUSDrzAHJGrzKA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=SF4pzp+TJdnLn6LX3/Yy/CpsNT1w57k/n8PDOhJ4VkRg4QqYiZ+EDR90RmcEIEit2VGhVP9+LdCn1dg8MzaZ3TkeTRhYexc4c0fZyt6KvAIyzUYFI0xzH/JPCaLb4xWk2gPuvmGIwPDgoK8iGXFPT7yG2OW55SdgS5MJfCHTZuI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YGGcDOc9; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YGGcDOc9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 83B731F00898; Sat, 6 Jun 2026 20:06:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780776410; bh=b2uD+J314xoZnLe/CqhsMboKQCzCjaM1jNC4mWctMNo=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=YGGcDOc9KerUTTHKdC9aMpRzZLGBlsRdV6//dbtx+fuTh1VVArNsLWVprnU9nH6J0 Tco0IChjiaS8kSqD+HweB8uPrkthZCcF9Lizi2hthD77XTFHo1BgfP6JVjYztiVfbk O76kwPQIDZXR/Xmkgw4E/WnspF+Hyu/7Zkv9TXAfseu15LEXvWOdcMtacdPIsu6ULV qxZeDDcMXrMd9QOPzTtANfBofHo+yfXXkoKNAyPfdsC9ZfIPtD2010bHc09Vb4HruX CNeS3iZgvvjtgt5GuLhhydGh8WDTBvVUL8Pq74rv6sNx1N/CzzTWaPym/gjADL8i+0 Rv7n4lCXt3EGA== From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Ingo Molnar , Thomas Gleixner , James Clark , Jiri Olsa , Ian Rogers , Adrian Hunter , Clark Williams , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Arnaldo Carvalho de Melo , "Claude Opus 4.6" Subject: [PATCH 7/7] libperf: Document struct perf_cpu int16_t ABI limitation Date: Sat, 6 Jun 2026 17:05:59 -0300 Message-ID: <20260606200601.1861227-8-acme@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260606200601.1861227-1-acme@kernel.org> References: <20260606200601.1861227-1-acme@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Arnaldo Carvalho de Melo struct perf_cpu.cpu is int16_t, limiting perf to 32767 CPUs. This is part of the libperf ABI (returned by value from perf_cpu_map__cpu() and friends), so widening it requires an ABI bump. Add a comment on the struct definition noting this, and create a TODO file to collect future ABI changes so they can be batched into a single version bump. Cc: Ian Rogers Cc: Namhyung Kim Assisted-by: Claude Opus 4.6 Signed-off-by: Arnaldo Carvalho de Melo --- tools/lib/perf/TODO | 22 ++++++++++++++++++++++ tools/lib/perf/include/perf/cpumap.h | 8 +++++++- 2 files changed, 29 insertions(+), 1 deletion(-) create mode 100644 tools/lib/perf/TODO diff --git a/tools/lib/perf/TODO b/tools/lib/perf/TODO new file mode 100644 index 0000000000000000..486dd95dc57208a8 --- /dev/null +++ b/tools/lib/perf/TODO @@ -0,0 +1,22 @@ +Future ABI changes +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +This file collects items that require a libperf ABI bump. Each entry +should describe the current limitation, the desired end state, and the +scope of the change so that a future ABI revision can batch them +together. + +1. Widen struct perf_cpu.cpu from int16_t to int + - Current limit: 32767 CPUs. No architecture exceeds this today + (x86_64 max is 8192, arm64 is 4096), but NR_CPUS limits keep + growing. perf clamps to INT16_MAX in set_max_cpu_num() as a + safety net. + - Scope: struct perf_cpu is embedded everywhere =E2=80=94 perf_cpu_map_= _cpu(), + perf_cpu_map__min(), perf_cpu_map__max(), perf_cpu_map__has(), the + for_each_cpu macros, and all internal callers. The perf_cpu_map + internal array (RC_CHK_ACCESS(map)->map[]) stores struct perf_cpu + directly. Widening changes the struct layout and every function + that returns or accepts struct perf_cpu by value. + - Migration: bump LIBPERF version in libperf.map, audit all + sizeof(struct perf_cpu) assumptions, update perf.data + serialization if needed. diff --git a/tools/lib/perf/include/perf/cpumap.h b/tools/lib/perf/include/= perf/cpumap.h index a1dd25db65b62f6b..e1a0b0d272109ecb 100644 --- a/tools/lib/perf/include/perf/cpumap.h +++ b/tools/lib/perf/include/perf/cpumap.h @@ -6,7 +6,13 @@ #include #include =20 -/** A wrapper around a CPU to avoid confusion with the perf_cpu_map's map'= s indices. */ +/** + * struct perf_cpu - wrapper around a CPU number. + * @cpu: CPU number, -1 for the "any CPU"/dummy value. + * + * int16_t limits this to 32767 CPUs. Widening to int requires a libperf + * ABI bump =E2=80=94 see tools/lib/perf/TODO for the full scope. + */ struct perf_cpu { int16_t cpu; }; --=20 2.54.0