linux-kernel - Re: [PATCH v1 2/2] perf metricgroup: Don't early exit if no CPUID table exists

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]

Message-ID: <CAP-5=fV8ofWn2oYDip3pOX7+Cx0GyKckq_o0Q6qahuoqgydN7w@mail.gmail.com>
Date: Fri, 6 Feb 2026 10:57:54 -0800
From: Ian Rogers <irogers@...gle.com>
To: Leo Yan <leo.yan@....com>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, 
	Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>, 
	Adrian Hunter <adrian.hunter@...el.com>, James Clark <james.clark@...aro.org>, 
	linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/2] perf metricgroup: Don't early exit if no CPUID
 table exists

On Fri, Feb 6, 2026 at 4:33 AM Leo Yan <leo.yan@....com> wrote:
>
> On Fri, Feb 06, 2026 at 10:45:43AM +0000, Leo Yan wrote:
> > On Thu, Feb 05, 2026 at 10:36:03AM -0800, Ian Rogers wrote:
> > > The failure to find a table of metrics with a CPUID shouldn't early
> > > exit as the metric code will now also consider the default table.
> > > When searching for a metric or metric group,
> > > pmu_metrics_table__for_each_metric considers all tables and so the
> > > caller doesn't need to switch the table to do this.
> > >
> > > Fixes: c7adeb0974f1 ("perf jevents: Add set of common metrics based on default ones")
> > > Signed-off-by: Ian Rogers <irogers@...gle.com>
> > > ---
> > >  tools/perf/util/metricgroup.c | 18 +++++-------------
> > >  1 file changed, 5 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> > > index 40a1e14de418..46bf4dfeebc8 100644
> > > --- a/tools/perf/util/metricgroup.c
> > > +++ b/tools/perf/util/metricgroup.c
> > > @@ -1562,8 +1562,6 @@ int metricgroup__parse_groups(struct evlist *perf_evlist,
> > >  {
> > >     const struct pmu_metrics_table *table = pmu_metrics_table__find();
> > >
> > > -   if (!table)
> > > -           return -EINVAL;
> > >     if (hardware_aware_grouping)
> > >             pr_debug("Use hardware aware grouping instead of traditional metric grouping method\n");
> > >
> > > @@ -1601,22 +1599,16 @@ static int metricgroup__has_metric_or_groups_callback(const struct pmu_metric *p
> > >
> > >  bool metricgroup__has_metric_or_groups(const char *pmu, const char *metric_or_groups)
> > >  {
> > > -   const struct pmu_metrics_table *tables[2] = {
> > > -           pmu_metrics_table__find(),
> > > -           pmu_metrics_table__default(),
> > > -   };
> > > +   const struct pmu_metrics_table *table = pmu_metrics_table__find();
> >
> > Here should be:
> >
> >   const struct pmu_metrics_table *table = pmu_metrics_table__default();
>
> Or, I think you should not change metricgroup__has_metric_or_groups().
> The change only in metricgroup__parse_groups() can fix my issue.

This is wrong and the patch I tested I believe to be correct. The
table here is CPUID associated table and all the metric code will
bottom out in metricgroup__for_each_metric where the CPUID table is
the table parameter (its a parameter because of testing where we force
the machine/model to "testarch"):
https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/metricgroup.c?h=perf-tools-next#n430
```
int metricgroup__for_each_metric(const struct pmu_metrics_table
*table, pmu_metric_iter_fn fn, void *data)
{
...
const struct pmu_metrics_table *tables[2] = {
    table,
    pmu_metrics_table__default(),
};

for (size_t i = 0; i < ARRAY_SIZE(tables); i++) {
    int ret;

    if (!tables[i])
        continue;
```
If you make the table here the default table then you will process the
default table twice in metricgroup__for_each_metric which will mean
double metric look ups, etc. So I think the patch is correct and
passed my testing both with and without NO_JEVENTS=1.

Thanks,
Ian

> Thanks,
> Leo