All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: Wei Li <liwei391@huawei.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Alexey Budankov <alexey.budankov@linux.intel.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	huawei.libin@huawei.com, Namhyung Kim <namhyung@kernel.org>,
	Jiri Olsa <jolsa@redhat.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] perf stat: Fix segfault when counting armv8_pmu events
Date: Tue, 22 Sep 2020 12:50:35 -0700	[thread overview]
Message-ID: <20200922195035.GA42577@tassilo.jf.intel.com> (raw)
In-Reply-To: <20200922192321.GL13818@tassilo.jf.intel.com>

On Tue, Sep 22, 2020 at 12:23:21PM -0700, Andi Kleen wrote:
> > After debugging, i found the root reason is that the xyarray fd is created
> > by evsel__open_per_thread() ignoring the cpu passed in
> > create_perf_stat_counter(), while the evsel' cpumap is assigned as the
> > corresponding PMU's cpumap in __add_event(). Thus, the xyarray fd is created
> > with ncpus of dummy cpumap and an out of bounds 'cpu' index will be used in
> > perf_evsel__close_fd_cpu().
> > 
> > To address this, add a flag to mark this situation and avoid using the
> > affinity technique when closing/enabling/disabling events.
> 
> The flag seems like a hack. How about figuring out the correct number of 
> CPUs and using that?

Also would like to understand what's different on ARM64 than other architectures.
Or could this happen on x86 too?

-Andi

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <ak@linux.intel.com>
To: Wei Li <liwei391@huawei.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Alexey Budankov <alexey.budankov@linux.intel.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, huawei.libin@huawei.com
Subject: Re: [PATCH 1/2] perf stat: Fix segfault when counting armv8_pmu events
Date: Tue, 22 Sep 2020 12:50:35 -0700	[thread overview]
Message-ID: <20200922195035.GA42577@tassilo.jf.intel.com> (raw)
In-Reply-To: <20200922192321.GL13818@tassilo.jf.intel.com>

On Tue, Sep 22, 2020 at 12:23:21PM -0700, Andi Kleen wrote:
> > After debugging, i found the root reason is that the xyarray fd is created
> > by evsel__open_per_thread() ignoring the cpu passed in
> > create_perf_stat_counter(), while the evsel' cpumap is assigned as the
> > corresponding PMU's cpumap in __add_event(). Thus, the xyarray fd is created
> > with ncpus of dummy cpumap and an out of bounds 'cpu' index will be used in
> > perf_evsel__close_fd_cpu().
> > 
> > To address this, add a flag to mark this situation and avoid using the
> > affinity technique when closing/enabling/disabling events.
> 
> The flag seems like a hack. How about figuring out the correct number of 
> CPUs and using that?

Also would like to understand what's different on ARM64 than other architectures.
Or could this happen on x86 too?

-Andi

  reply	other threads:[~2020-09-22 19:51 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-22  3:13 [PATCH 0/2] perf stat: Unbreak perf stat with ARMv8 PMU events Wei Li
2020-09-22  3:13 ` Wei Li
2020-09-22  3:13 ` [PATCH 1/2] perf stat: Fix segfault when counting armv8_pmu events Wei Li
2020-09-22  3:13   ` Wei Li
2020-09-22 19:23   ` Andi Kleen
2020-09-22 19:23     ` Andi Kleen
2020-09-22 19:50     ` Andi Kleen [this message]
2020-09-22 19:50       ` Andi Kleen
2020-09-24 14:14       ` liwei (GF)
2020-09-24 14:14         ` liwei (GF)
2020-09-23  5:44   ` Jiri Olsa
2020-09-23  5:44     ` Jiri Olsa
2020-09-23 13:49     ` Namhyung Kim
2020-09-23 13:49       ` Namhyung Kim
2020-09-23 14:07       ` Jiri Olsa
2020-09-23 14:07         ` Jiri Olsa
2020-09-23 14:15         ` Namhyung Kim
2020-09-23 14:15           ` Namhyung Kim
2020-09-23 20:19           ` Jiri Olsa
2020-09-23 20:19             ` Jiri Olsa
2020-09-24 14:36             ` Namhyung Kim
2020-09-24 14:36               ` Namhyung Kim
2020-09-25 21:01               ` Jiri Olsa
2020-09-25 21:01                 ` Jiri Olsa
2020-10-02  8:59               ` Jiri Olsa
2020-10-02  8:59                 ` Jiri Olsa
2020-10-06  6:51                 ` Song Bao Hua (Barry Song)
2020-10-06  6:51                   ` Song Bao Hua (Barry Song)
2020-09-22  3:13 ` [PATCH 2/2] perf stat: Unbreak perf stat with " Wei Li
2020-09-22  3:13   ` Wei Li

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=20200922195035.GA42577@tassilo.jf.intel.com \
    --to=ak@linux.intel.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexey.budankov@linux.intel.com \
    --cc=huawei.libin@huawei.com \
    --cc=jolsa@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liwei391@huawei.com \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    /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.