Re: [PATCH v2] perf build: Fix compiler errors with old capstone

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Leaked `struct map *` reference in `print_capstone_detail` due to missing `map__put()`.
--

--- Patch [1]: [PATCH v2] perf build: Fix compiler errors with old capstone ---
commit 290412dd8be8c32690d86ead2197a90f8b8eb074
Author: Namhyung Kim <namhyung@kernel.org>

perf build: Fix compiler errors with old capstone

This commit fixes build failures on older capstone versions (prior to v5) by
defining missing RISC-V architectural and mode constants.

> diff --git a/tools/perf/util/capstone.c b/tools/perf/util/capstone.c
> index 5ad537fea4360..0247142a77ba3 100644
> --- a/tools/perf/util/capstone.c
> +++ b/tools/perf/util/capstone.c
> @@ -24,6 +24,13 @@
>  #include "symbol.h"
>  #include "thread.h"
>  
> +#if CS_VERSION_MAJOR < 5
> +#define CS_ARCH_RISCV    15
> +#define CS_MODE_RISCV32  1
> +#define CS_MODE_RISCV64  2
> +#define CS_MODE_RISCVC   4
> +#endif

[ ... ]

Later in tools/perf/util/capstone.c:print_capstone_detail():

> 		if (dso__kernel(map__dso(map))) {
> 			/*
> 			 * The kernel maps can be split into sections, let's
> 			 * find the map first and the search the symbol.
> 			 */
> 			map = maps__find(map__kmaps(map), addr);

[Severity: High]
This isn't a bug introduced by this patch, but does this code leak the map
reference?

When disassembling instructions with X86 memory operands using RIP-relative
addressing, maps__find() returns a new reference to the kernel section map.
Since this new reference is assigned to the local map variable, is there a
missing map__put() before the function returns or the loop continues? This
might lead to a resource leak and reference count imbalance.

> 			if (map == NULL)
> 				continue;
> 		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706234836.815254-1-namhyung@kernel.org?part=1