linux-kernel - Re: [PATCH v2 03/13] perf hist: Add missing puts to hist__account

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]

Date:   Tue, 24 Oct 2023 09:12:33 -0700
From:   Ian Rogers <irogers@...gle.com>
To:     Namhyung Kim <namhyung@...nel.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...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>,
        Nick Terrell <terrelln@...com>,
        Kan Liang <kan.liang@...ux.intel.com>,
        Song Liu <song@...nel.org>,
        Sandipan Das <sandipan.das@....com>,
        Anshuman Khandual <anshuman.khandual@....com>,
        James Clark <james.clark@....com>,
        Liam Howlett <liam.howlett@...cle.com>,
        Miguel Ojeda <ojeda@...nel.org>, Leo Yan <leo.yan@...aro.org>,
        German Gomez <german.gomez@....com>,
        Ravi Bangoria <ravi.bangoria@....com>,
        Artem Savkov <asavkov@...hat.com>,
        Athira Rajeev <atrajeev@...ux.vnet.ibm.com>,
        Andi Kleen <ak@...ux.intel.com>, linux-kernel@...r.kernel.org,
        linux-perf-users@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH v2 03/13] perf hist: Add missing puts to hist__account_cycles

On Wed, Oct 18, 2023 at 4:16 PM Namhyung Kim <namhyung@...nel.org> wrote:
>
> Hi Ian,
>
> On Wed, Oct 11, 2023 at 11:24 PM Ian Rogers <irogers@...gle.com> wrote:
> >
> > Caught using reference count checking on perf top with
> > "--call-graph=lbr". After this no memory leaks were detected.
> >
> > Fixes: 57849998e2cd ("perf report: Add processing for cycle histograms")
> > Signed-off-by: Ian Rogers <irogers@...gle.com>
> > ---
> >  tools/perf/util/hist.c | 10 +++++++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
> > index 3dc8a4968beb..ac8c0ef48a7f 100644
> > --- a/tools/perf/util/hist.c
> > +++ b/tools/perf/util/hist.c
> > @@ -2676,8 +2676,6 @@ void hist__account_cycles(struct branch_stack *bs, struct addr_location *al,
> >
> >         /* If we have branch cycles always annotate them. */
> >         if (bs && bs->nr && entries[0].flags.cycles) {
> > -               int i;
> > -
>
> Seems not necessary.
>
> >                 bi = sample__resolve_bstack(sample, al);
>
> It looks like this increases the refcount for each bi entry and
> it didn't put the refcounts.

Right, this is why the loop doing the puts is added.

>
> >                 if (bi) {
> >                         struct addr_map_symbol *prev = NULL;
> > @@ -2692,7 +2690,7 @@ void hist__account_cycles(struct branch_stack *bs, struct addr_location *al,
> >                          * Note that perf stores branches reversed from
> >                          * program order!
> >                          */
> > -                       for (i = bs->nr - 1; i >= 0; i--) {
> > +                       for (int i = bs->nr - 1; i >= 0; i--) {
> >                                 addr_map_symbol__account_cycles(&bi[i].from,
> >                                         nonany_branch_mode ? NULL : prev,
> >                                         bi[i].flags.cycles);
> > @@ -2701,6 +2699,12 @@ void hist__account_cycles(struct branch_stack *bs, struct addr_location *al,
> >                                 if (total_cycles)
> >                                         *total_cycles += bi[i].flags.cycles;
> >                         }
> > +                       for (unsigned int i = 0; i < bs->nr; i++) {
>
> Can we just reuse the int i above?

I wanted to move to unsigned for consistency with the rest of the
branch_stack code, nr is a u64, but when iterating down the sign
matters - so this fixes up where possible.

Thanks,
Ian

> Thanks,
> Namhyung
>
>
> > +                               map__put(bi[i].to.ms.map);
> > +                               maps__put(bi[i].to.ms.maps);
> > +                               map__put(bi[i].from.ms.map);
> > +                               maps__put(bi[i].from.ms.maps);
> > +                       }
> >                         free(bi);
> >                 }
> >         }
> > --
> > 2.42.0.609.gbb76f46606-goog
> >