Re: [PATCH v2 3/8] perf symbol: Fall back to fetching the vmlinux by build ID

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Holding `dso->lock` across a blocking debuginfod network fetch causes lock starvation.
--

commit 0a14099ecb356d49e5d4b366cbd27b6a6caf40b8
Author: Arnaldo Carvalho de Melo <acme@redhat.com>

perf symbol: Fall back to fetching the vmlinux by build ID

This commit adds a fallback mechanism to fetch the vmlinux keyed by its build
ID using the debuginfod client when local kernel symbols cannot be found.

> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
[ ... ]
> +static int dso__load_vmlinux_build_id(struct dso *dso, struct map *map)
> +{
> +	char *path = NULL;
> +
> +	if (!dso__has_build_id(dso))
> +		return -1;
> +
> +	if (debuginfo__find_build_id(dso__bid(dso), &path))

[Severity: Medium]
Does holding the dso lock across this debuginfod network fetch cause lock
starvation?

When a perf profile is missing local kernel symbols, dso__load() acquires
dso->lock and subsequently calls dso__load_kernel_sym(), which then calls
dso__load_vmlinux_build_id(). This results in the blocking call to
debuginfo__find_build_id() executing while dso->lock is still held.

Could a slow network fetch or timeout stall all concurrent accesses to the
same kernel DSO by other threads, potentially impacting tool responsiveness
(such as in perf top) or parallel processing?

> +		return -1;
> +
> +	/* Takes ownership of 'path' even when it fails */
> +	return dso__load_vmlinux(dso, map, path, true);
> +}
[ ... ]

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