Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp5117468pxv; Tue, 20 Jul 2021 20:15:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzibgMNZGV7nOCk4YdNtzfcJVDQoesYrD5CSNKuJtTaoRNX2SY5tBAYZpQd10V2RsWCVOT7 X-Received: by 2002:a05:6402:b8a:: with SMTP id cf10mr45499699edb.61.1626837358153; Tue, 20 Jul 2021 20:15:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626837358; cv=none; d=google.com; s=arc-20160816; b=KXydLOoQGveNsmODX+99h9swYegKVVYIe2j8zyivDSQADpJY1JxiinM3JQ8t10bd5R XpkUfxjTC2jqMU/d0o/EvKxbZToPNhsMbtrqkue9TPVr8w4oLOzyEx3Q4upoKlNha5kv B4gLtUtohaZDvRmTmtdOkK8SfK8Cpmcddoc06OSEIZVtewvfrNWYKbgMt938VTB8HiKW xInNfrhsVpdosRJ1z40z7R4tdGsaIwQlER/3+SJ7+c5N09wMzz0L60efSvAMJXa2TEKX diwHs3T0B0N1hoOGsSifkfNDVT+3oa2dFbtDaE6lfFzQSb0Pj3cc6SPt420a0+Vv/AJ7 mXpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=dkYqgLDWNOtEbP/vemWeYFWkmzES4rERp2Owj/FhhEE=; b=tYpQt11y6WtJdpSnmSFplcl739H6ml48GCUGPGUlBj881pCknchoyZxlDmiLJg4tsW x2VWsIgmyCkgQAMSk+ZZKeD/3iQlYvnZkkKI0zV/yZ/TBHbY8ds3ZM62HF/Pn/YorO+B XSz8lezEqzxQra5d7M5TB5Ok+bAXBuh+z68yEO9VazJH2cYecl37WD9BbdhyxiO5YjxS Mp+g66Em2/TIa/U6gL1usBrn9yemRDAF15G2DzOl2jTnNfny/dZtVaf0h162f4epl7sq E/w4msnpu/UkNWzk0s2TLPxnAXP0eJa0uCuj5KhotSf4zbisOkyo++pjkI7gsH5y65iY MhRQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f2si26853916edw.161.2021.07.20.20.15.35; Tue, 20 Jul 2021 20:15:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232397AbhGUCd2 (ORCPT + 99 others); Tue, 20 Jul 2021 22:33:28 -0400 Received: from mga05.intel.com ([192.55.52.43]:40963 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232187AbhGUC24 (ORCPT ); Tue, 20 Jul 2021 22:28:56 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10051"; a="296924415" X-IronPort-AV: E=Sophos;i="5.84,256,1620716400"; d="scan'208";a="296924415" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2021 20:08:04 -0700 X-IronPort-AV: E=Sophos;i="5.84,256,1620716400"; d="scan'208";a="501122354" Received: from yjin15-mobl1.ccr.corp.intel.com (HELO [10.238.4.147]) ([10.238.4.147]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2021 20:08:02 -0700 Subject: Re: [PATCH] perf pmu: Fix alias matching To: John Garry , peterz@infradead.org, mingo@redhat.com, acme@kernel.org, mark.rutland@arm.com, jolsa@redhat.com, namhyung@kernel.org, kjain@linux.ibm.com, alexander.shishkin@linux.intel.com, irogers@google.com Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org References: <1626793819-79090-1-git-send-email-john.garry@huawei.com> From: "Jin, Yao" Message-ID: <0b57fa9b-fba4-8143-bef6-b7c4f2987635@linux.intel.com> Date: Wed, 21 Jul 2021 11:07:59 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <1626793819-79090-1-git-send-email-john.garry@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Garry, On 7/20/2021 11:10 PM, John Garry wrote: > Commit c47a5599eda32 ("perf tools: Fix pattern matching for same substring > in different PMU type"), may have fixed some alias matching, but has broken > some others. > > Firstly it cannot handle the simple scenario of PMU name in form > pmu_name{digits} - it can only handle pmu_name_{digits}. > > Secondly it cannot handle more complex matching in the case where we have > multiple tokens. In this scenario, the code failed to realise that we > may examine multiple substrings in the PMU name. > > Fix in two ways: > - Change perf_pmu__valid_suffix() to accept a PMU name without '_' in the > suffix > - Only pay attention to perf_pmu__valid_suffix() for the final token > > Also add const qualifiers as necessary to avoid casting. > > Fixes: c47a5599eda3 ("perf tools: Fix pattern matching for same substring in different PMU type") > Signed-off-by: John Garry > --- > @Jin Yao, please test for your scenarios > For x86, the form uncore_pmu_{digits} or the uncore_pmu itself are supported. We don't have more complex case such as the name in the form aaa_bbbX_cccY. So my test didn't cover that complex form. For my test, your patch works, thanks! :) > Note: > About any effect in perf_pmu__match() -> perf_pmu__valid_suffix() > callchain, this seems to be called for wildcard in PMU names in metric > expressions. We don't have any metrics for arm64 which use feature. > However, I hacked an existing metric to use a wildcard and it looks ok. > Also the "DRAM_BW_Use" metric on my broadwell uses this feature, and it > looks ok. > > diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c > index a1bd7007a8b4..fc683bc41715 100644 > --- a/tools/perf/util/pmu.c > +++ b/tools/perf/util/pmu.c > @@ -742,9 +742,13 @@ struct pmu_events_map *__weak pmu_events_map__find(void) > return perf_pmu__find_map(NULL); > } > > -static bool perf_pmu__valid_suffix(char *pmu_name, char *tok) > +/* > + * Suffix must be in form tok_{digits}, or tok{digits}, or same as pmu_name > + * to be valid. > + */ > +static bool perf_pmu__valid_suffix(const char *pmu_name, char *tok) > { > - char *p; > + const char *p; > > if (strncmp(pmu_name, tok, strlen(tok))) > return false; > @@ -753,12 +757,16 @@ static bool perf_pmu__valid_suffix(char *pmu_name, char *tok) > if (*p == 0) > return true; > > - if (*p != '_') > - return false; > + if (*p == '_') > + ++p; > > - ++p; > - if (*p == 0 || !isdigit(*p)) > - return false; > + /* Ensure we end in a number */ > + while (1) { > + if (!isdigit(*p)) > + return false; > + if (*(++p) == 0) > + break; > + } > Do we check *p before first isdigit? For example, if (*p == 0) return false; While (*p) { if (!isdigit(*p) return false; ++p; } But maybe isdigit can handle the null string well. I'm just feeling a bit unsure. > return true; > } > @@ -789,12 +797,19 @@ bool pmu_uncore_alias_match(const char *pmu_name, const char *name) > * match "socket" in "socketX_pmunameY" and then "pmuname" in > * "pmunameY". > */ > - for (; tok; name += strlen(tok), tok = strtok_r(NULL, ",", &tmp)) { > + while (1) { > + char *next_tok = strtok_r(NULL, ",", &tmp); > + > name = strstr(name, tok); > - if (!name || !perf_pmu__valid_suffix((char *)name, tok)) { > + if (!name || > + (!next_tok && !perf_pmu__valid_suffix(name, tok))) { > res = false; > goto out; > } > + if (!next_tok) > + break; > + tok = next_tok; > + name += strlen(tok); > } > > res = true; > My test didn't cover the tokens which were delimited by ','. I assume you have tested that on arm64 system. :) Thanks Jin Yao