From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A3B25C2BC61 for ; Tue, 30 Oct 2018 13:27:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6651120848 for ; Tue, 30 Oct 2018 13:27:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="AjJWx/fP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6651120848 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728204AbeJ3WUk (ORCPT ); Tue, 30 Oct 2018 18:20:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:51556 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727576AbeJ3WUk (ORCPT ); Tue, 30 Oct 2018 18:20:40 -0400 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3C98C20827; Tue, 30 Oct 2018 13:27:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1540906032; bh=Rz/UwiOhIfNWVmh2EDFO0+PSlcnZmlx9LrJBwgJ8JsM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AjJWx/fPjss7JRf96VrhN8eGmeD3OXQvrlPLZj7WC8BHUr0qWzke9tfV1BYsKFCm4 wkqyWncqxx5alO50wl4EfnUmpC1VwLArt6BaqY6hnFaDsGRrvkTauazwGaBXJrKgRL 1/5sjHvD82moPySOmmUbYE7sMU8ssKtAQE9tIweM= From: Sasha Levin To: stable@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Jiri Olsa , Alexander Shishkin , Andi Kleen , Kan Liang , Namhyung Kim , Peter Zijlstra , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH AUTOSEL 4.18 04/33] Revert "perf tools: Fix PMU term format max value calculation" Date: Tue, 30 Oct 2018 09:26:28 -0400 Message-Id: <20181030132657.217970-4-sashal@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20181030132657.217970-1-sashal@kernel.org> References: <20181030132657.217970-1-sashal@kernel.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jiri Olsa [ Upstream commit 1b9caa10b31dda0866f4028e4bfb923fb6e4072f ] This reverts commit ac0e2cd555373ae6f8f3a3ad3fbbf5b6d1e7aaaa. Michael reported an issue with oversized terms values assignment and I noticed there was actually a misunderstanding of the max value check in the past. The above commit's changelog says: If bit 21 is set, there is parsing issues as below. $ perf stat -a -e uncore_qpi_0/event=0x200002,umask=0x8/ event syntax error: '..pi_0/event=0x200002,umask=0x8/' \___ value too big for format, maximum is 511 But there's no issue there, because the event value is distributed along the value defined by the format. Even if the format defines separated bit, the value is treated as a continual number, which should follow the format definition. In above case it's 9-bit value with last bit separated: $ cat uncore_qpi_0/format/event config:0-7,21 Hence the value 0x200002 is correctly reported as format violation, because it exceeds 9 bits. It should have been 0x102 instead, which sets the 9th bit - the bit 21 of the format. $ perf stat -vv -a -e uncore_qpi_0/event=0x102,umask=0x8/ Using CPUID GenuineIntel-6-2D ... ------------------------------------------------------------ perf_event_attr: type 10 size 112 config 0x200802 sample_type IDENTIFIER ... Reported-by: Michael Petlan Signed-off-by: Jiri Olsa Cc: Alexander Shishkin Cc: Andi Kleen Cc: Kan Liang Cc: Namhyung Kim Cc: Peter Zijlstra Fixes: ac0e2cd55537 ("perf tools: Fix PMU term format max value calculation") Link: http://lkml.kernel.org/r/20181003072046.29276-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin --- tools/perf/util/pmu.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c index 3ba6a1742f91..02580f3ded1a 100644 --- a/tools/perf/util/pmu.c +++ b/tools/perf/util/pmu.c @@ -936,13 +936,14 @@ static void pmu_format_value(unsigned long *format, __u64 value, __u64 *v, static __u64 pmu_format_max_value(const unsigned long *format) { - __u64 w = 0; - int fbit; - - for_each_set_bit(fbit, format, PERF_PMU_FORMAT_BITS) - w |= (1ULL << fbit); + int w; - return w; + w = bitmap_weight(format, PERF_PMU_FORMAT_BITS); + if (!w) + return 0; + if (w < 64) + return (1ULL << w) - 1; + return -1; } /* -- 2.17.1