[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200922195035.GA42577@tassilo.jf.intel.com>
Date: Tue, 22 Sep 2020 12:50:35 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Wei Li <liwei391@...wei.com>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
Alexey Budankov <alexey.budankov@...ux.intel.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, huawei.libin@...wei.com
Subject: Re: [PATCH 1/2] perf stat: Fix segfault when counting armv8_pmu
events
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
Powered by blists - more mailing lists