Re: [PATCH v6 5/9] perf c2c: add function view stats merge and memory management

[email protected] Mon, 03 Aug 2026 04:01:31 +0000
Newsgroups org.kernel.vger.linux-perf-users
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [Medium] Pruning level-2 writers leaves dangling pointers in `hroot_in` t=
ree.
--

--- Patch [5]: [PATCH v6 5/9] perf c2c: add function view stats merge and m=
emory management ---
commit 0e7c26167764aee56c787657f5359beaaecb5f75
Author: Jiebin Sun <[email protected]>

perf c2c: add function view stats merge and memory management

Add the per-entry stats/cstats aggregation helpers and hierarchy teardown.
Child common fields are released through hist_entry__delete(), while the
function-view free callback handles the private child tree and containing
allocation. Also add a helper for pruning writer entries with no stores or
cacheline children.

> diff --git a/tools/perf/ui/browsers/c2c-function.c b/tools/perf/ui/browse=
rs/c2c-function.c
> index 7e26c4d1147f4..fc9a4c4bcb03f 100644
> --- a/tools/perf/ui/browsers/c2c-function.c
> +++ b/tools/perf/ui/browsers/c2c-function.c

[ ... ]

> @@ -683,6 +683,168 @@ c2c_function_hists__reinit(struct c2c_hists *c2c_hi=
sts,

[ ... ]

> +static int __maybe_unused c2c_he__prune_empty_writers(struct hist_entry =
*l1_he)
> +{
> +	struct rb_node *nd;
> +	int surviving =3D 0;
> +
> +	if (!l1_he->has_children)
> +		return 0;
> +
> +	nd =3D rb_first_cached(&l1_he->hroot_out);
> +	while (nd) {
> +		struct rb_node *next =3D rb_next(nd);
> +		struct hist_entry *l2_he =3D rb_entry(nd, struct hist_entry, rb_node);
> +
> +		if (l2_he->has_children && hist_entry__displayed_stores(l2_he) > 0) {
> +			surviving++;
> +		} else {
> +			rb_erase_cached(&l2_he->rb_node, &l1_he->hroot_out);
> +			hist_entry__delete(l2_he);

[Severity: Medium]
Will this leave a dangling pointer in the parent's hroot_in tree?

When hist_entry__delete() frees l2_he in c2c_he__prune_empty_writers(), it
appears to only be unlinked from l1_he->hroot_out. If l1_he->hroot_in is
subsequently traversed (for example, during a TUI resort operation like
hists__hierarchy_output_resort()), could this lead to a use-after-free
crash when dereferencing the freed l2_he pointer?

> +		}
> +		nd =3D next;
> +	}
> +
> +	if (!surviving) {
> +		l1_he->hroot_out =3D RB_ROOT_CACHED;
> +		l1_he->has_children =3D false;
> +		l1_he->unfolded =3D false;
> +	}
> +	return surviving;
> +}

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260803035220.1720=
[email protected]?part=3D5