Re: [PATCH v6 21/21] TEST(do-not-upstream): fake qemu vendor JSON + mapfile entry for CounterIDMask path

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] This patch is explicitly marked 'TEST(do-not-upstream)' and adds fake testing events, which should not be merged into the mainline kernel.

Pre-existing issues:
- [High] Unconditional NULL pointer dereference in `get_cpuid`.
--

commit d0ac889c30ab39821cba995143de6c24abe2efcc
Author: Atish Patra <atishp@meta.com>

TEST(do-not-upstream): fake qemu vendor JSON + mapfile entry for CounterIDMask path

This patch adds fake QEMU vendor JSON events and a corresponding mapfile entry
for the CounterIDMask path to test PMU masking.

> diff --git a/tools/perf/pmu-events/arch/riscv/mapfile.csv b/tools/perf/pmu-events/arch/riscv/mapfile.csv
> index 87cfb0e0849fc..3533a8c0253f7 100644
> --- a/tools/perf/pmu-events/arch/riscv/mapfile.csv
> +++ b/tools/perf/pmu-events/arch/riscv/mapfile.csv
> @@ -24,3 +24,4 @@
>  0x602-0x3-0x0,v1,openhwgroup/cva6,core
>  0x67e-0x80000000db0000[89]0-0x[[:xdigit:]]+,v1,starfive/dubhe-80,core
>  0x31e-0x8000000000008a45-0x[[:xdigit:]]+,v1,andes/ax45,core
> +0x0-0x0-0x0,v1,qemu/virt,core

[Severity: Medium]
Since this patch is explicitly marked "TEST(do-not-upstream)" and adds fake
PMU events strictly for testing, should it be merged into the mainline
kernel?

Merging this will populate the perf tool's PMU event tables with non-existent
hardware events.

> diff --git a/tools/perf/pmu-events/arch/riscv/qemu/virt/events.json b/tools/perf/pmu-events/arch/riscv/qemu/virt/events.json
> new file mode 100644
> index 0000000000000..294c4ed645f67
> --- /dev/null
> +++ b/tools/perf/pmu-events/arch/riscv/qemu/virt/events.json
> @@ -0,0 +1,26 @@
> +[
> +  {
> +    "EventName": "fake-json-any",

[ ... ]

While reviewing this, I also noticed a pre-existing issue in
tools/perf/arch/riscv/util/header.c:

tools/perf/arch/riscv/util/header.c:get_cpuid() {
    ...
	char *cpuid = _get_cpuid();
	int ret = 0;

	if (sz < strlen(cpuid)) {
		ret = -EINVAL;
		goto free;
	}
    ...
}

[Severity: High]
This is a pre-existing issue, but can get_cpuid() cause a segmentation fault
here? If _get_cpuid() returns NULL (for example, if /proc/cpuinfo is missing
or lacks specific fields in a container or QEMU without proper emulation), it
appears the unconditional call to strlen(cpuid) will dereference that NULL
pointer.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608-counter_delegation-v6-0-285b72ed65a9@meta.com?part=21