lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <277a02a5-9355-4f06-9158-026cf4b330f7@linux.intel.com>
Date: Wed, 7 Aug 2024 09:27:02 -0400
From: "Liang, Kan" <kan.liang@...ux.intel.com>
To: Ian Rogers <irogers@...gle.com>, Peter Zijlstra <peterz@...radead.org>,
 Ingo Molnar <mingo@...hat.com>, Arnaldo Carvalho de Melo <acme@...nel.org>,
 Namhyung Kim <namhyung@...nel.org>, Mark Rutland <mark.rutland@....com>,
 Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
 Jiri Olsa <jolsa@...nel.org>, Adrian Hunter <adrian.hunter@...el.com>,
 Sun Haiyong <sunhaiyong@...ngson.cn>, Yanteng Si <siyanteng@...ngson.cn>,
 linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] perf hist: Fix reference counting of branch_info



On 2024-08-07 2:51 a.m., Ian Rogers wrote:
> iter_finish_branch_entry doesn't put the branch_info from/to map
> elements creating memory leaks. This can be seen with:
> 
> ```
> $ perf record -e cycles -b perf test -w noploop
> $ perf report -D
> ...
> Direct leak of 984344 byte(s) in 123043 object(s) allocated from:
>     #0 0x7fb2654f3bd7 in malloc libsanitizer/asan/asan_malloc_linux.cpp:69
>     #1 0x564d3400d10b in map__get util/map.h:186
>     #2 0x564d3400d10b in ip__resolve_ams util/machine.c:1981
>     #3 0x564d34014d81 in sample__resolve_bstack util/machine.c:2151
>     #4 0x564d34094790 in iter_prepare_branch_entry util/hist.c:898
>     #5 0x564d34098fa4 in hist_entry_iter__add util/hist.c:1238
>     #6 0x564d33d1f0c7 in process_sample_event tools/perf/builtin-report.c:334
>     #7 0x564d34031eb7 in perf_session__deliver_event util/session.c:1655
>     #8 0x564d3403ba52 in do_flush util/ordered-events.c:245
>     #9 0x564d3403ba52 in __ordered_events__flush util/ordered-events.c:324
>     #10 0x564d3402d32e in perf_session__process_user_event util/session.c:1708
>     #11 0x564d34032480 in perf_session__process_event util/session.c:1877
>     #12 0x564d340336ad in reader__read_event util/session.c:2399
>     #13 0x564d34033fdc in reader__process_events util/session.c:2448
>     #14 0x564d34033fdc in __perf_session__process_events util/session.c:2495
>     #15 0x564d34033fdc in perf_session__process_events util/session.c:2661
>     #16 0x564d33d27113 in __cmd_report tools/perf/builtin-report.c:1065
>     #17 0x564d33d27113 in cmd_report tools/perf/builtin-report.c:1805
>     #18 0x564d33e0ccb7 in run_builtin tools/perf/perf.c:350
>     #19 0x564d33e0d45e in handle_internal_command tools/perf/perf.c:403
>     #20 0x564d33cdd827 in run_argv tools/perf/perf.c:447
>     #21 0x564d33cdd827 in main tools/perf/perf.c:561
> ...
> ```
> 
> Clearing up the map_symbols properly creates maps reference count
> issues so resolve those. Resolving this issue doesn't improve peak
> heap consumption for the test above.
> 
> Signed-off-by: Ian Rogers <irogers@...gle.com>


Reviewed-by: Kan Liang <kan.liang@...ux.intel.com>

Thanks,
Kan

> ---
>  tools/perf/util/hist.c | 18 ++++++++++++++----
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
> index f8ee1cd6929d..c8c1b511f8a7 100644
> --- a/tools/perf/util/hist.c
> +++ b/tools/perf/util/hist.c
> @@ -472,7 +472,9 @@ static int hist_entry__init(struct hist_entry *he,
>  		memcpy(he->branch_info, template->branch_info,
>  		       sizeof(*he->branch_info));
>  
> +		he->branch_info->from.ms.maps = maps__get(he->branch_info->from.ms.maps);
>  		he->branch_info->from.ms.map = map__get(he->branch_info->from.ms.map);
> +		he->branch_info->to.ms.maps = maps__get(he->branch_info->to.ms.maps);
>  		he->branch_info->to.ms.map = map__get(he->branch_info->to.ms.map);
>  	}
>  
> @@ -970,10 +972,21 @@ iter_add_next_branch_entry(struct hist_entry_iter *iter, struct addr_location *a
>  	return err;
>  }
>  
> +static void branch_info__exit(struct branch_info *bi)
> +{
> +	map_symbol__exit(&bi->from.ms);
> +	map_symbol__exit(&bi->to.ms);
> +	zfree_srcline(&bi->srcline_from);
> +	zfree_srcline(&bi->srcline_to);
> +}
> +
>  static int
>  iter_finish_branch_entry(struct hist_entry_iter *iter,
>  			 struct addr_location *al __maybe_unused)
>  {
> +	for (int i = 0; i < iter->total; i++)
> +		branch_info__exit(&iter->bi[i]);
> +
>  	zfree(&iter->bi);
>  	iter->he = NULL;
>  
> @@ -1319,10 +1332,7 @@ void hist_entry__delete(struct hist_entry *he)
>  	map_symbol__exit(&he->ms);
>  
>  	if (he->branch_info) {
> -		map_symbol__exit(&he->branch_info->from.ms);
> -		map_symbol__exit(&he->branch_info->to.ms);
> -		zfree_srcline(&he->branch_info->srcline_from);
> -		zfree_srcline(&he->branch_info->srcline_to);
> +		branch_info__exit(he->branch_info);
>  		zfree(&he->branch_info);
>  	}
>  

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ