Message ID | 20221201055103.302019-1-anshuman.khandual@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp96249wrr; Wed, 30 Nov 2022 22:04:06 -0800 (PST) X-Google-Smtp-Source: AA0mqf6sH8kkbhF9zgYU97XO95U5rE3oTiRh+v/u3KoEeVVCJdPMBoEsBXJFfGY+TpNcS9g8oBAL X-Received: by 2002:a17:90a:4892:b0:216:92a9:fd50 with SMTP id b18-20020a17090a489200b0021692a9fd50mr68314826pjh.126.1669874645806; Wed, 30 Nov 2022 22:04:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669874645; cv=none; d=google.com; s=arc-20160816; b=okEm3El3n+BCwhQ9CY1/ZfQcP8IIVf3bnLs4Fshe3jR8dfe8giqDsPXPC50LHczFWQ 6wfitL/7fE7EGaQRkY+TdcmkgStXBtVRoBMeFpM1F4AvPzAc5JxuPRCQzYA+ibnOLp1B Jeygg5lf9b6bJjgasLZArzUZdIqliA6cykHOvf7Bmv3yk7nN0DTbsDUJpn2HKSrRIrLJ efDokTyVtKSp6W3scEcfAnjmJK7Hiwa++yDjUSet8A6sgOcs4KhrRCyXVHkym71GGSXv n+gXTjc0bfKpir8QP1Yd5w9ZMk//eSOX6xF3QLGhnaYRqWkaIGDPT24irIMxY6tmGG+W rBIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=qKmbB3acE5bF3m08mvHDdYh/d1mqm4qMS70n04dR5yc=; b=0Ua3lypMDOUgupLd1u/Mg2W/bRbd4FxZcPWTovTdK0QYqkq8NoO6AP817qebDc2+Tu hs5ZGvJ6CsccACsDTzQYG6pwvXLVUh+5D2IZ1XEllNq64IyUsA6Y9paSbaDjHuq3qlgH Yvrg9sSYX/bV1V7M3l8A5BRYr4Zi0aN/TG34CPjMN0PdLzeVfl1veIeloLNGrjj7JACN HNEP6IP1LSx2AtW0X8SaT3vRd/XFyj2sR7acDeYZAcIuTAPsuK9juyTaKoiGS81qjo9M cBYTLta46iIoKdvff7ST4w3NCXPGqR+RPTYZSEFE0J9X+pBgyxAEIRysTtl86WtY3lvV pZDg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a39-20020a056a001d2700b00561898445bdsi3686627pfx.273.2022.11.30.22.03.45; Wed, 30 Nov 2022 22:04:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229686AbiLAFvU (ORCPT <rfc822;heyuhang3455@gmail.com> + 99 others); Thu, 1 Dec 2022 00:51:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35200 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229689AbiLAFvR (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 1 Dec 2022 00:51:17 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 23504A6B45; Wed, 30 Nov 2022 21:51:15 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 070FBD6E; Wed, 30 Nov 2022 21:51:22 -0800 (PST) Received: from a077893.blr.arm.com (unknown [10.162.43.8]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 935B93F73D; Wed, 30 Nov 2022 21:51:11 -0800 (PST) From: Anshuman Khandual <anshuman.khandual@arm.com> To: linux-kernel@vger.kernel.org Cc: james.clark@arm.com, Anshuman Khandual <anshuman.khandual@arm.com>, Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>, Arnaldo Carvalho de Melo <acme@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>, linux-perf-users@vger.kernel.org Subject: [PATCH] perf/core: Reset remaining bits in perf_clear_branch_entry_bitfields() Date: Thu, 1 Dec 2022 11:21:03 +0530 Message-Id: <20221201055103.302019-1-anshuman.khandual@arm.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750990476385182425?= X-GMAIL-MSGID: =?utf-8?q?1750990476385182425?= |
Series |
perf/core: Reset remaining bits in perf_clear_branch_entry_bitfields()
|
|
Commit Message
Anshuman Khandual
Dec. 1, 2022, 5:51 a.m. UTC
perf_clear_branch_entry_bitfields() resets all struct perf_branch_entry bit
fields before capturing branch records. This resets remaining bit fields
except 'new_type', which is valid only when 'type' is PERF_BR_EXTEND_ABI.
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: linux-perf-users@vger.kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
This applies on v6.1-rc6
'perf_branch_entry.new_type' can remain uninitialized as explained earlier.
Also there is no PERF_BR_NEW_UNKNOWN to spare, because 'perf_branch_entry.
new_type' enumeration starts at PERF_BR_NEW_FAULT_ALGN, to save a position
for the extended branch types instead.
include/linux/perf_event.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Comments
On 01/12/2022 05:51, Anshuman Khandual wrote: > perf_clear_branch_entry_bitfields() resets all struct perf_branch_entry bit > fields before capturing branch records. This resets remaining bit fields > except 'new_type', which is valid only when 'type' is PERF_BR_EXTEND_ABI. > > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: Arnaldo Carvalho de Melo <acme@kernel.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> > Cc: Jiri Olsa <jolsa@kernel.org> > Cc: Namhyung Kim <namhyung@kernel.org> > Cc: linux-perf-users@vger.kernel.org> > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> > --- > This applies on v6.1-rc6 > > 'perf_branch_entry.new_type' can remain uninitialized as explained earlier. > Also there is no PERF_BR_NEW_UNKNOWN to spare, because 'perf_branch_entry. > new_type' enumeration starts at PERF_BR_NEW_FAULT_ALGN, to save a position > for the extended branch types instead. > > include/linux/perf_event.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h > index 0031f7b4d9ab..c97b5f6f77a4 100644 > --- a/include/linux/perf_event.h > +++ b/include/linux/perf_event.h > @@ -1110,8 +1110,9 @@ static inline void perf_clear_branch_entry_bitfields(struct perf_branch_entry *b > br->in_tx = 0; > br->abort = 0; > br->cycles = 0; > - br->type = 0; > + br->type = PERF_BR_UNKNOWN; > br->spec = PERF_BR_SPEC_NA; > + br->priv = PERF_BR_PRIV_UNKNOWN; > br->reserved = 0; > } I would vote for just memsetting the whole struct to 0 at this point and making it work by ensuring the cleared from and to values are only set after this function. Or do the thing where it's wrapped in a union and the 'u64 value' member is assigned 0. See union perf_mem_data_src. I don't know if this would be a breaking change, but it doesn't look like it. Currently this is a bit too fragile and the kind of bugs it will cause are almost undetectable. But as my proposal is an extra change on top of this: Reviewed-by: James Clark <james.clark@arm.com> James >
On 12/1/22 11:21, Anshuman Khandual wrote: > perf_clear_branch_entry_bitfields() resets all struct perf_branch_entry bit > fields before capturing branch records. This resets remaining bit fields > except 'new_type', which is valid only when 'type' is PERF_BR_EXTEND_ABI. > > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: Arnaldo Carvalho de Melo <acme@kernel.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> > Cc: Jiri Olsa <jolsa@kernel.org> > Cc: Namhyung Kim <namhyung@kernel.org> > Cc: linux-perf-users@vger.kernel.org> > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> > --- > This applies on v6.1-rc6 > > 'perf_branch_entry.new_type' can remain uninitialized as explained earlier. > Also there is no PERF_BR_NEW_UNKNOWN to spare, because 'perf_branch_entry. > new_type' enumeration starts at PERF_BR_NEW_FAULT_ALGN, to save a position > for the extended branch types instead. > > include/linux/perf_event.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h > index 0031f7b4d9ab..c97b5f6f77a4 100644 > --- a/include/linux/perf_event.h > +++ b/include/linux/perf_event.h > @@ -1110,8 +1110,9 @@ static inline void perf_clear_branch_entry_bitfields(struct perf_branch_entry *b > br->in_tx = 0; > br->abort = 0; > br->cycles = 0; > - br->type = 0; > + br->type = PERF_BR_UNKNOWN; > br->spec = PERF_BR_SPEC_NA; > + br->priv = PERF_BR_PRIV_UNKNOWN; > br->reserved = 0; > } > Hello Peter, Just wondering is there a chance that this patch could make it to v6.2-rc1 ? - Anshuman
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h index 0031f7b4d9ab..c97b5f6f77a4 100644 --- a/include/linux/perf_event.h +++ b/include/linux/perf_event.h @@ -1110,8 +1110,9 @@ static inline void perf_clear_branch_entry_bitfields(struct perf_branch_entry *b br->in_tx = 0; br->abort = 0; br->cycles = 0; - br->type = 0; + br->type = PERF_BR_UNKNOWN; br->spec = PERF_BR_SPEC_NA; + br->priv = PERF_BR_PRIV_UNKNOWN; br->reserved = 0; }