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: <YNuNW/Afd/X25fNe@krava>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ