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 17:47:56 -0400
From:   "Liang, Kan" <kan.liang@...ux.intel.com>
To:     Jiri Olsa <jolsa@...hat.com>, "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 6/29/2021 5:15 PM, Jiri Olsa wrote:
> 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.. 

Yes, I agree. One function is better.

We just changed the design for the uncore PMU on SPR. There will be two 
PMU names for each uncore unit, a real name and an alias. The perf tool 
should handle both names. So we have to compare both names here.
I think one generic function can facilitate the code rebase.

https://lore.kernel.org/lkml/1624990443-168533-7-git-send-email-kan.liang@linux.intel.com/

Thanks,
Kan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ