linux-kernel - Re: [PATCH RFC v3 02/12] perf jevents: Add support for system events tables

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAP-5=fWHipkL6Uq1vMaz-51ETPWajofDXd6RTBMr00pcyooo_g@mail.gmail.com>
Date:   Mon, 11 May 2020 09:21:00 -0700
From:   Ian Rogers <irogers@...gle.com>
To:     John Garry <john.garry@...wei.com>
Cc:     Jiri Olsa <jolsa@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Namhyung Kim <namhyung@...nel.org>, will@...nel.org,
        Andi Kleen <ak@...ux.intel.com>, linuxarm@...wei.com,
        LKML <linux-kernel@...r.kernel.org>, qiangqing.zhang@....com,
        robin.murphy@....com, zhangshaokun@...ilicon.com,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH RFC v3 02/12] perf jevents: Add support for system events tables

On Mon, May 11, 2020 at 8:03 AM John Garry <john.garry@...wei.com> wrote:
>
> On 11/05/2020 12:01, Jiri Olsa wrote:
> > On Thu, May 07, 2020 at 07:57:41PM +0800, John Garry wrote:
> >
> > SNIP
> >
> >> +                                  &sys_event_tables);
> >> +            }
> >> +
> >>              print_events_table_prefix(eventsfp, tblname);
> >>              return 0;
> >>      }
> >> @@ -1180,7 +1253,6 @@ int main(int argc, char *argv[])
> >>      } else if (rc < 0) {
> >>              /* Make build fail */
> >>              fclose(eventsfp);
> >> -            free_arch_std_events();
> >>              ret = 1;
> >>              goto out_free_mapfile;
> >>      } else if (rc) {
> >> @@ -1206,27 +1278,31 @@ int main(int argc, char *argv[])
> >>      if (close_table)
> >>              print_events_table_suffix(eventsfp);
> >>
> >> -    if (!mapfile) {
> >> -            pr_info("%s: No CPU->JSON mapping?\n", prog);
> >> -            goto empty_map;
> >> +    if (mapfile) {
> >> +            if (process_mapfile(eventsfp, mapfile)) {
> >> +                    pr_err("%s: Error processing mapfile %s\n", prog,
> >> +                           mapfile);
> >> +                    /* Make build fail */
> >> +                    fclose(eventsfp);
> >> +                    ret = 1;
> >> +            }
> >> +    } else {
> >> +            pr_err("%s: No CPU->JSON mapping?\n", prog);
> >
> > shouldn't we jump to empty_map in here? there still needs to be a
> > mapfile, right?
>
> In theory we could only support sys events :)
>
> But I'll now make this a (empty map) failure case. And I think that
> another error case handling needs fixing in my patch.
>
>
> As for this:
>
>   +     fprintf(outfp, "struct pmu_sys_events pmu_sys_event_tables[] = {");
>  >> +
>  >> +   list_for_each_entry(sys_event_table, &sys_event_tables, list) {
>  >> +           fprintf(outfp, "\n\t{\n\t\t.table = %s,\n\t},",
>  >> +                   sys_event_table->name);
>  >> +   }
>  >> +   fprintf(outfp, "\n\t{\n\t\t.table = 0\n\t},");
>  >
>  > this will add extra tabs:
>  >
>  >          {
>  >                  .table = 0
>  >          },
>  >
>  > while the rest of the file starts items without any indent
>  >
>
> I'll ensure the indent is the same.
>
> BTW, is there anything to be said for removing the empty map feature
> (and always breaking the perf build instead)? I guess that it was just
> an early feature for dealing with unstable JSONs.

+1
I'd very much like it if JSON parse errors and the like didn't result
in an empty map but failed the build. I think ideally we could also
validate metric expressions using expr.y. If we include expr.y into
jevents then is there any need to parse the metric expression at
runtime? Could we just generate C code from jevents with a list of
events (aka ids) for programming and a dedicated print function for
each metric. The events would still be symbolic and checked at
runtime, but the expressions being C code could yield compile time
errors.

Thanks,
Ian

> Thanks,
> john
>
> >
> > jirka
> >
> >>      }
> >>
> >> -    if (process_mapfile(eventsfp, mapfile)) {
> >> -            pr_info("%s: Error processing mapfile %s\n", prog, mapfile);
> >> -            /* Make build fail */
> >> +    if (process_system_event_tables(eventsfp)) {
> >>              fclose(eventsfp);
> >> -            free_arch_std_events();
> >>              ret = 1;
> >>      }
> >>
> >> -
> >>      goto out_free_mapfile;
> >>
> >>   empty_map:
> >>      fclose(eventsfp);
> >>      create_empty_mapping(output_file);
> >> -    free_arch_std_events();
> >>   out_free_mapfile:
> >> +    free_arch_std_events();
> >> +    free_sys_event_tables();
> >>      free(mapfile);
> >>      return ret;
> >>   }
> >
> > SNIP
> >
> > .
> >
>