linux-kernel - Re: [PATCH v1] perf tools: Fix pattern matching for same substring used in different pmu type

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]

Date:   Tue, 29 Jun 2021 23:15:07 +0200
From:   Jiri Olsa <jolsa@...hat.com>
To:     "Jin, Yao" <yao.jin@...ux.intel.com>
Cc:     acme@...nel.org, jolsa@...nel.org, peterz@...radead.org,
        mingo@...hat.com, alexander.shishkin@...ux.intel.com,
        Linux-kernel@...r.kernel.org, ak@...ux.intel.com,
        kan.liang@...el.com, yao.jin@...el.com
Subject: Re: [PATCH v1] perf tools: Fix pattern matching for same substring
 used in different pmu type

On Mon, Jun 28, 2021 at 09:52:42AM +0800, Jin, Yao wrote:

SNIP

> > > > > +    /*
> > > > > +     * The pmu_name has substring tok. If the format of
> > > > > +     * pmu_name is <tok> or <tok>_<digit>, return true.
> > > > > +     */
> > > > > +    p = pmu_name + strlen(tok);
> > > > > +    if (*p == 0)
> > > > > +        return true;
> > > > > +
> > > > > +    if (*p != '_')
> > > > > +        return false;
> > > > > +
> > > > > +    ++p;
> > > > > +    if (*p == 0 || !isdigit(*p))
> > > > > +        return false;
> > > > > +
> > > > > +    return true;
> > > > > +}
> > 
> > hum, so we have pattern serch and then another function checking
> > if that search was ok..
> 
> Yes, that's what this patch does.
> 
> I understand that's convenient, because
> > it's on 2 different places
> 
> Yes, on pmu_uncore_alias_match() and on parse-events.y.
> 
> but could we have some generic solution,
> > line one function/search that returns/search for valid pmu name?
> > 
> 
> Sorry, I don't understand this idea well. Would you like to further explain?
> 
> Or can you accept the regex approach?

I don't really have any suggestion, just would be great to have
this encapsulated in one function.. but if there's not any good
one, we can go with this change

Andi, Kan, are you ok with this change?

thanks,
jirka