Re: [PATCH 2/4] perf script: Add --max-symbol-bytes to bound ELF symbol memory

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] perf: data race and underflow on global symbol_bytes_used counter
- [High] perf: early abort of ELF symbol loading stretches symbols over address gaps
- [Medium] perf: u16 truncation in sym->namelen causes permanent memory budget leak
--

commit c9eea40a0a34f49638af63c080650086fd45e844
Author: Alireza Haghdoost <haghdoost@uber.com>

perf script: Add --max-symbol-bytes to bound ELF symbol memory

This patch adds a --max-symbol-bytes option to bound the memory allocated
for struct symbol when loading ELF symbols. Once the budget is reached,
further loading is aborted to prevent OOM kills.

> diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> index e955c3feddcd6..914e42d21f70f 100644
> --- a/tools/perf/util/symbol-elf.c
> +++ b/tools/perf/util/symbol-elf.c
> @@ -1634,6 +1634,13 @@ dso__load_sym_internal(struct dso *dso, struct map *map, struct symsrc *syms_ss,
>  		int is_label = elf_sym__is_label(&sym);
>  		const char *section_name;
>  		bool used_opd = false;
> +		if (symbol_conf.max_symbol_bytes &&
> +		    symbol__bytes_used() >= symbol_conf.max_symbol_bytes) {
> +			pr_warning_once("perf: symbol memory budget exceeded (%lu bytes), "
> +					"remaining symbols will be [unknown]\n",
> +					symbol_conf.max_symbol_bytes);
> +			break;

[Severity: High]
Since ELF symbol tables are generally not sorted by address (they are grouped
by binding), breaking out of the loop early creates random gaps in the
address space. Following this, symbols__fixup_end() iterates the partially
loaded rb-tree and stretches any zero-length symbols to the start address of
the very next loaded symbol (prev->end = curr->start).

Will this cause execution samples originating in the missing un-symbolized
gaps to be incorrectly attributed to completely unrelated, stretched
zero-length symbols instead of falling back to [unknown]?

[ ... ]
> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index 3587ad2431590..62a4f91c2f5db 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
[ ... ]
> +static size_t symbol_bytes_used;
> +
> +size_t symbol__bytes_used(void)
> +{
> +	return symbol_bytes_used;
> +}
> +
> +void symbol__account_bytes(size_t bytes)
> +{
> +	symbol_bytes_used += bytes;
> +}
> +
> +void symbol__unaccount_bytes(size_t bytes)
> +{
> +	symbol_bytes_used -= bytes;
> +}

[Severity: High]
The global symbol_bytes_used is updated without atomic operations. In
multi-threaded tools like perf top where different DSOs are loaded
concurrently by different threads, will concurrent updates cause lost
increments?

If subsequent decrements succeed, this could underflow symbol_bytes_used to
SIZE_MAX, instantly exhausting the memory budget and breaking all further
symbol resolution.

> +
>  struct symbol *symbol__new(u64 start, u64 len, u8 binding, u8 type, const char *name)
>  {
>  	size_t namelen = strlen(name) + 1;
> -	struct symbol *sym = calloc(1, (symbol_conf.priv_size +
> -					sizeof(*sym) + namelen));
> +	size_t alloc_size = symbol_conf.priv_size + sizeof(struct symbol) + namelen;
> +	struct symbol *sym;
> +
> +	sym = calloc(1, alloc_size);
>  	if (sym == NULL)
>  		return NULL;
>  
> +	symbol__account_bytes(alloc_size);
> +
[ ... ]
>  void symbol__delete(struct symbol *sym)
>  {
> +	size_t alloc_size = symbol_conf.priv_size + sizeof(struct symbol) +
> +			    sym->namelen + 1;

[Severity: Medium]
If a symbol name exceeds 65,535 bytes (which is possible with deeply mangled
C++ or Rust templates), the u16 sym->namelen field silently wraps when it is
assigned during allocation.

When symbol__delete() recalculates the budget to subtract using this truncated
u16 value, will it result in a much smaller subtraction than the original
addition, acting as a permanent memory budget leak that artificially exhausts
the limit?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915-perf-symbol-memory-send-v1-0-1d3360e21f07@uber.com?part=2