linux-kernel - [Question] perf tools: lex parsing issue

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-next>] [day] [month] [year] [list]

Date:   Mon, 23 Aug 2021 12:27:43 +0100
From:   John Garry <john.garry@...wei.com>
To:     Jiri Olsa <jolsa@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>,
        "Peter Zijlstra" <peterz@...radead.org>,
        "irogers@...gle.com" <irogers@...gle.com>,
        Ingo Molnar <mingo@...hat.com>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Namhyung Kim <namhyung@...nel.org>
Subject: [Question] perf tools: lex parsing issue

Hi jirka,

If you remember from some time ago we discussed how the lex parsing 
creates strange aliases:

https://lore.kernel.org/lkml/20200320093006.GA1343171@krava/

I am no expert on l+y, but it seems that we simply don't set the term 
config field for known term types. Well, not for 
PARSE_EVENTS__TERM_TYPE_SAMPLE_PERIOD type anyway.

This super hack resolves that issue:

--->8----

--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -765,7 +765,12 @@ event_config ',' event_term
struct list_head *head = $1;
struct parse_events_term *term = $3

+ if (term->type_term == PARSE_EVENTS__TERM_TYPE_SAMPLE_PERIOD) {
+ 	term->config = strdup("period");
+ }
+
if (!head) {
	parse_events_term__delete(term);
	YYABORT;
-- 

----8-----

So we get "umask=0x80,period=0x30d40,event=0x6" now, rather than 
"umask=0x80,(null)=0x30d40,event=0x6", for the perf_pmu_alias.str, as an 
example.

Did you ever get a chance to look into this issue? Do you know how could 
or should this field be set properly?

Some more background:
The reason I was looking at this is because I think it causes a problem 
for pmu-events (JSONs) aliasing for some PMUs. Specifically it's PMU 
which use "config=xxx" in sysfs files in 
/sys/bus/event_source/devices/PMUx/events/, rather than "event=xxx". The 
actual problem is that I trigger this warn in pmu.c:

static void perf_pmu_assign_str(char *name, const char *field, char 
**old_str,
char **new_str)
{

if (*new_str) { /* Have new string, check with old */
	if (strcasecmp(*old_str, *new_str))
		pr_debug("alias %s differs i ... <---

As I get "config=event=0xXXX" vs "config=(null)=0xXXX"

As I am not sure how to solve that yet, but, since we have 
config=(null), I thought it best to solve the first issue first.

Thanks,
John