All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Stephane Eranian <eranian@google.com>
Cc: Numfor Mbiziwo-Tiapo <nums@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Song Liu <songliubraving@fb.com>,
	mbd@fb.com, LKML <linux-kernel@vger.kernel.org>,
	Ian Rogers <irogers@google.com>
Subject: Re: [PATCH] Fix perf stat repeat segfault
Date: Mon, 15 Jul 2019 09:59:12 +0200	[thread overview]
Message-ID: <20190715075912.GA2821@krava> (raw)
In-Reply-To: <CABPqkBSq35HZVk2CNi8xy9j7eb3EWRXSdgPKd+fmv2XaKPjOqA@mail.gmail.com>

On Sun, Jul 14, 2019 at 02:36:42PM -0700, Stephane Eranian wrote:
> On Sun, Jul 14, 2019 at 1:55 PM Jiri Olsa <jolsa@redhat.com> wrote:
> >
> > On Sun, Jul 14, 2019 at 10:44:36PM +0200, Jiri Olsa wrote:
> > > On Wed, Jul 10, 2019 at 01:45:40PM -0700, Numfor Mbiziwo-Tiapo wrote:
> > > > When perf stat is called with event groups and the repeat option,
> > > > a segfault occurs because the cpu ids are stored on each iteration
> > > > of the repeat, when they should only be stored on the first iteration,
> > > > which causes a buffer overflow.
> > > >
> > > > This can be replicated by running (from the tip directory):
> > > >
> > > > make -C tools/perf
> > > >
> > > > then running:
> > > >
> > > > tools/perf/perf stat -e '{cycles,instructions}' -r 10 ls
> > > >
> > > > Since run_idx keeps track of the current iteration of the repeat,
> > > > only storing the cpu ids on the first iteration (when run_idx < 1)
> > > > fixes this issue.
> > > >
> > > > Signed-off-by: Numfor Mbiziwo-Tiapo <nums@google.com>
> > > > ---
> > > >  tools/perf/builtin-stat.c | 7 ++++---
> > > >  1 file changed, 4 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> > > > index 63a3afc7f32b..92d6694367e4 100644
> > > > --- a/tools/perf/builtin-stat.c
> > > > +++ b/tools/perf/builtin-stat.c
> > > > @@ -378,9 +378,10 @@ static void workload_exec_failed_signal(int signo __maybe_unused, siginfo_t *inf
> > > >     workload_exec_errno = info->si_value.sival_int;
> > > >  }
> > > >
> > > > -static bool perf_evsel__should_store_id(struct perf_evsel *counter)
> > > > +static bool perf_evsel__should_store_id(struct perf_evsel *counter, int run_idx)
> > > >  {
> > > > -   return STAT_RECORD || counter->attr.read_format & PERF_FORMAT_ID;
> > > > +   return STAT_RECORD || counter->attr.read_format & PERF_FORMAT_ID
> > > > +           && run_idx < 1;
> > >
> > > we create counters for every iteration, so this can't be
> > > based on iteration
> > >
> > > I think that's just a workaround for memory corruption,
> > > that's happening for repeating groupped events stats,
> > > I'll check on this
> >
> > how about something like this? we did not cleanup
> > ids on evlist close, so it kept on raising and
> > causing corruption in next iterations
> >
> not sure, that would realloc on each iteration of the repeats.

well, we need new ids, because we create new events every iteration

jirka

> 
> >
> > jirka
> >
> >
> > ---
> > diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> > index ebb46da4dfe5..52459dd5ad0c 100644
> > --- a/tools/perf/util/evsel.c
> > +++ b/tools/perf/util/evsel.c
> > @@ -1291,6 +1291,7 @@ static void perf_evsel__free_id(struct perf_evsel *evsel)
> >         xyarray__delete(evsel->sample_id);
> >         evsel->sample_id = NULL;
> >         zfree(&evsel->id);
> > +       evsel->ids = 0;
> >  }
> >
> >  static void perf_evsel__free_config_terms(struct perf_evsel *evsel)
> > @@ -2077,6 +2078,7 @@ void perf_evsel__close(struct perf_evsel *evsel)
> >
> >         perf_evsel__close_fd(evsel);
> >         perf_evsel__free_fd(evsel);
> > +       perf_evsel__free_id(evsel);
> >  }
> >
> >  int perf_evsel__open_per_cpu(struct perf_evsel *evsel,

  reply	other threads:[~2019-07-15  7:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10 20:45 [PATCH] Fix perf stat repeat segfault Numfor Mbiziwo-Tiapo
2019-07-11  4:44 ` Ravi Bangoria
2019-07-14 20:44 ` Jiri Olsa
2019-07-14 20:55   ` Jiri Olsa
2019-07-14 21:36     ` Stephane Eranian
2019-07-15  7:59       ` Jiri Olsa [this message]
2019-07-15  8:14         ` Stephane Eranian
2019-07-15  8:31           ` Jiri Olsa
2019-07-15 14:21             ` [PATCH] perf stat: Fix segfault for event group in repeat mode Jiri Olsa
2019-07-16 18:48               ` Arnaldo Carvalho de Melo
2019-07-23 21:49               ` [tip:perf/urgent] " tip-bot for Jiri Olsa
2019-07-11 17:21 [PATCH] Fix perf stat repeat segfault Numfor Mbiziwo-Tiapo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190715075912.GA2821@krava \
    --to=jolsa@redhat.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbd@fb.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=nums@google.com \
    --cc=peterz@infradead.org \
    --cc=songliubraving@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.