On Mon, Dec 4, 2023 at 12:22 PM Arnaldo Carvalho de Melo
[off-list ref] wrote:

Em Mon, Dec 04, 2023 at 05:20:46PM -0300, Arnaldo Carvalho de Melo escreveu:

quoted

Em Mon, Dec 04, 2023 at 12:12:54PM -0800, Ian Rogers escreveu:

quoted

On Thu, Nov 23, 2023 at 8:01 AM Athira Rajeev
[off-list ref] wrote:

quoted

Running "perf list" on powerpc fails with segfault
as below:

   ./perf list
   Segmentation fault (core dumped)

This happens because of duplicate events in the json list.
The powerpc Json event list contains some event with same
event name, but different event code. They are:
- PM_INST_FROM_L3MISS (Present in datasource and frontend)
- PM_MRK_DATA_FROM_L2MISS (Present in datasource and marked)
- PM_MRK_INST_FROM_L3MISS (Present in datasource and marked)
- PM_MRK_DATA_FROM_L3MISS (Present in datasource and marked)

pmu_events_table__num_events uses the value from
table_pmu->num_entries which includes duplicate events as
well. This causes issue during "perf list" and results in
segmentation fault.

Since both event codes are valid, append _DSRC to the Data
Source events (datasource.json), so that they would have a
unique name. Also add PM_DATA_FROM_L2MISS_DSRC and
PM_DATA_FROM_L3MISS_DSRC events. With the fix, perf list
works as expected.

Fixes: fc1435807533 ("perf vendor events power10: Update JSON/events")
Signed-off-by: Athira Rajeev <redacted>

Given duplicate events creates broken pmu-events.c we should capture
that as an exception in jevents.py. That way a JEVENTS_ARCH=all build
will fail if any vendor/architecture would break in this way. We
should also add JEVENTS_ARCH=all to tools/perf/tests/make. Athira, do
you want to look at doing this?

Should I go ahead and remove this patch till this is sorted out?

I'll keep it, its already in tmp.perf-tools-next, we can go from there
and improve this with follow up patches,

Agreed. I could look to do the follow up but likely won't have a
chance for a while. If others could help out it would be great. I'd
like to have the jevents and json be robust enough that we don't trip
over problems like this and the somewhat similar AmpereOne issue.

Thanks,
Ian

- Arnaldo