Re: [PATCH v1 1/2] perf tool: Remove util/cache.h

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Removal of `util/cache.h` removes implicit inclusions of standard POSIX headers, causing musl compatibility violations due to missing explicit includes.
--

commit 6e76c8b7f671374f4e87596d7f1af0426551795a
Author: Ian Rogers <irogers@google.com>

perf tool: Remove util/cache.h

Move definitions to places they are used, or path.h in the case of
path.c's mkpath function. Remove unused definitions. Fix transitive
include dependencies.

> diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
> --- a/tools/perf/builtin-annotate.c
> +++ b/tools/perf/builtin-annotate.c
> @@ -11,7 +11,6 @@
>  
>  #include "util/color.h"
>  #include <linux/list.h>
> -#include "util/cache.h"
>  #include <linux/rbtree.h>
>  #include "util/symbol.h"

[Severity: Low]
Does the removal of util/cache.h drop implicit inclusions of standard POSIX
headers? This file uses standard string and allocation functions, so it
seems <string.h> and <stdlib.h> need to be explicitly included to avoid
build failures on systems using musl libc.

[ ... ]

> diff --git a/tools/perf/util/path.c b/tools/perf/util/path.c
> --- a/tools/perf/util/path.c
> +++ b/tools/perf/util/path.c
> @@ -1,6 +1,5 @@
>  // SPDX-License-Identifier: GPL-2.0
>  #include "path.h"
> -#include "cache.h"
>  #include <linux/kernel.h>
>  #include <limits.h>

[Severity: Low]
With cache.h removed, does mkpath() now lack the required <stdarg.h> include?
Looking at mkpath() later in this file, it relies on va_start(args, fmt) which
requires <stdarg.h>. Without the explicit include, this causes musl
compatibility violations.

[ ... ]

> diff --git a/tools/perf/util/strbuf.c b/tools/perf/util/strbuf.c
> --- a/tools/perf/util/strbuf.c
> +++ b/tools/perf/util/strbuf.c
> @@ -1,5 +1,4 @@
>  // SPDX-License-Identifier: GPL-2.0
> -#include "cache.h"
>  #include "debug.h"
>  #include "strbuf.h"

[Severity: Low]
Should <string.h> be explicitly included here? Looking at strbuf_add(), it
uses memcpy(), and relying on <linux/string.h> instead of the standard POSIX
header can cause namespace pollution and musl compilation failures.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828222045.1314766-1-irogers@google.com?part=1