Re: [PATCH] perf dwarf-aux: Check .eh_frame section for CFA

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] perf: memory leak of Dwarf_CFI handle in die_get_cfa()
- [Medium] perf: severe performance degradation from repeatedly parsing .eh_frame
--

commit 63cd38e63157cedd873e0aa6adbf63746489d27e
Author: Namhyung Kim <namhyung@kernel.org>

perf dwarf-aux: Check .eh_frame section for CFA

This commit modifies die_get_cfa() to first attempt to retrieve the
.eh_frame section using dwarf_getcfi_elf() before falling back to the
.debug_frame section.

[Severity: Medium]
Does this code leak the dynamically allocated Dwarf_CFI object?

In tools/perf/util/dwarf-aux.c within die_get_cfa(), dwarf_getcfi_elf() is
called to get the .eh_frame section. Unlike dwarf_getcfi(), which returns a
structure owned by the Dwarf context, dwarf_getcfi_elf() allocates a new
Dwarf_CFI object that the caller must free using dwarf_cfi_end().

However, die_get_cfa() returns without freeing the cfi pointer on both the
success path and the error path. Since this function is called repeatedly
during data annotation, could this lead to rapid memory consumption?

[Severity: Medium]
Is there a risk of severe performance degradation here?

Calling dwarf_getcfi_elf() reads and parses the .eh_frame section to
dynamically build a search index for the module. Because die_get_cfa() is a
heavily utilized helper function often called repeatedly, rebuilding this
index and allocating the structures from scratch on every single invocation
could cause massive CPU overhead.

Would it be possible to cache the .eh_frame Dwarf_CFI object to avoid
rebuilding it on every call?

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