From nobody Mon Jun 8 07:22:04 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ADFA62EEE7D; Fri, 5 Jun 2026 01:16:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780622219; cv=none; b=LUJBaQxurjlKtvJuVI7qSL7SjI/+Sqcb3nLSmrLY91f5FBW6A+GPP0jhmxRxo/RN/cSbMTsgVpQ/c91TkMPkvPE4/zeWVso5eUV2kjSnr6ezxrAtKKufoI+GqPUMu3Q2VJDR17hkkeoIAh8LdZrBSMwP//bgVdBYnUsHWGe7m9w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780622219; c=relaxed/simple; bh=DcBlyDR9rRPaOBESCLzdKkuax3RCUikTU/Z2mRglcNM=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=d+2Yn6uykkDQPG+EK/xvln96lyjnKvgoLfsn3Z7tZR26ZWdDrH9iwlt4jIPkEnvOU/S3/pf/PWYZ9uM9G8ACRwqxIGlISxnBDD6SaRqmQ4HRBFYVUIlUV2coLBK7m7vR32lovwk5r/cO93tmmjneHYTywbschuA8JiFd4nf297g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=UTDGqpPT; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="UTDGqpPT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1780622212; x=1812158212; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=DcBlyDR9rRPaOBESCLzdKkuax3RCUikTU/Z2mRglcNM=; b=UTDGqpPTuyCPX9qLq4un793eFDNH6XAz+UWb59L2oTRxR0akqgahlq4R cMytIVdO1nPuxEM7dKQ+qxqHjjZMh0AgsKigBTZxswiquHsZValRBLiPD G6D9zMGEeSkKEzcua1eq3i8RwwBfb+P7WxnRRpNrsMwa0M8rl2XVpZbJn gA9Qmw0gZpL8CyWFvKKpoGT2WOHnKDekqyl96DlYZPQ1ELmFgG301Kmbc tHidQKJ1sI8dp2WSQt/d5UCkn8K9c3vTUN/2o1rOC07X+P8xU9941iUL5 D8UclmNWIgJR91lxXqCVp3L4wSr7MtYlDL59Uo4Bwt8i9lH4DkfY3djgX Q==; X-CSE-ConnectionGUID: Gnt29DQZQLC7LLHCaLIIig== X-CSE-MsgGUID: smQxAtHzTzCVXxRJOAp2mA== X-IronPort-AV: E=McAfee;i="6800,10657,11807"; a="91772174" X-IronPort-AV: E=Sophos;i="6.24,188,1774335600"; d="scan'208";a="91772174" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jun 2026 18:16:52 -0700 X-CSE-ConnectionGUID: Mp66UqkiRkWguqJqPMCKsg== X-CSE-MsgGUID: 6lEzUOWUQkGFlTynMo6nQg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,188,1774335600"; d="scan'208";a="244817107" Received: from spr.sh.intel.com ([10.112.230.239]) by orviesa007.jf.intel.com with ESMTP; 04 Jun 2026 18:16:49 -0700 From: Dapeng Mi To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Ian Rogers , Adrian Hunter , Alexander Shishkin , Andi Kleen , Eranian Stephane Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Dapeng Mi , Zide Chen , Falcon Thomas , Xudong Hao , Dapeng Mi , stable@vger.kernel.org Subject: [PATCH 1/8] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities Date: Fri, 5 Jun 2026 09:11:29 +0800 Message-Id: <20260605011136.2043393-2-dapeng1.mi@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260605011136.2043393-1-dapeng1.mi@linux.intel.com> References: <20260605011136.2043393-1-dapeng1.mi@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" AnyThread mode deprecation is enumerated by CPUID.0AH:EDX[15] instead of PERF_CAPABILITIES MSR. It's not a good practice to define a bit to represent "anythread deprecation" in perf_capabilities. It leads to the anythread_deprecated bit could be overwritten by the real value of PERF_CAPABILITIES MSR, just like the below code in update_pmu_cap() does. ``` if (!intel_pmu_broken_perf_cap()) { /* Perf Metric (Bit 15) and PEBS via PT (Bit 16) are hybrid enumeration */ rdmsrq(MSR_IA32_PERF_CAPABILITIES, hybrid(pmu, intel_cap).capabilities); } ``` It leads to the anythread_deprecated bit is cleared to 0 and the "any" attribute is incorrectly shown in the /sys/devices/cpu/format/ folder on these support Perfmon v6 platforms, like Clearwater Forest. ``` $grep . /sys/devices/cpu/format/* /sys/devices/cpu/format/acr_mask:config2:0-63 /sys/devices/cpu/format/any:config:21 /sys/devices/cpu/format/cmask:config:24-31 ``` So remove the anythread_deprecated bit from perf_capabilities structure and directly depends on CPUID.0AH:EDX[15] to judge if anythread is deprecated. Cc: stable@vger.kernel.org Reported-by: Namhyung Kim Fixes: cadbaa039b99 ("perf/x86/intel: Make anythread filter support conditi= onal") Acked-by: Namhyung Kim Signed-off-by: Dapeng Mi Reviewed-by: Zide Chen Reviewed-by: Thomas Falcon --- Original patch link: https://lore.kernel.org/all/20260423053306.3033331-1-dapeng1.mi@linux.intel= .com/ arch/x86/events/intel/core.c | 10 +++------- arch/x86/events/perf_event.h | 2 +- 2 files changed, 4 insertions(+), 8 deletions(-) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index 0217e701aeeb..ea3ab3050a3b 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -7946,12 +7946,6 @@ __init int intel_pmu_init(void) =20 x86_add_quirk(intel_arch_events_quirk); /* Install first, so it runs last= */ =20 - if (version >=3D 5) { - x86_pmu.intel_cap.anythread_deprecated =3D edx.split.anythread_deprecate= d; - if (x86_pmu.intel_cap.anythread_deprecated) - pr_cont(" AnyThread deprecated, "); - } - /* The perf side of core PMU is ready to support the mediated vPMU. */ x86_get_pmu(smp_processor_id())->capabilities |=3D PERF_PMU_CAP_MEDIATED_= VPMU; =20 @@ -8828,8 +8822,10 @@ __init int intel_pmu_init(void) &x86_pmu.intel_ctrl); =20 /* AnyThread may be deprecated on arch perfmon v5 or later */ - if (x86_pmu.intel_cap.anythread_deprecated) + if (version >=3D 5 && edx.split.anythread_deprecated) { x86_pmu.format_attrs =3D intel_arch_formats_attr; + pr_cont("AnyThread deprecated, "); + } =20 intel_pmu_check_event_constraints_all(NULL); =20 diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h index eae24bb35dc1..5902a297daa1 100644 --- a/arch/x86/events/perf_event.h +++ b/arch/x86/events/perf_event.h @@ -668,7 +668,7 @@ union perf_capabilities { u64 perf_metrics:1; u64 pebs_output_pt_available:1; u64 pebs_timing_info:1; - u64 anythread_deprecated:1; + u64 __reserved:1; u64 rdpmc_metrics_clear:1; }; u64 capabilities; --=20 2.34.1 From nobody Mon Jun 8 07:22:04 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 51458378D8B; Fri, 5 Jun 2026 01:16:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780622223; cv=none; b=UdkW9ccMuNn830qmf4FvYTqk0zgurOEg+p3yfNGkkNBiG/rJvJuQqUgJvlnuu2A5923mOnGeoRxouWwLiL46RAaR2owWg1TrVGMJv6siEiFI5A4bRWHiuY4Y2SWCoxOtRe7758mixEWAul9WuEqW5AixvJtZK1inwUfRDgKuJL8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780622223; c=relaxed/simple; bh=99LaCPX5v3Uxh5M6N+wcyfmWLe5NRtFKC2Yvy4+Lvjk=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=dmNMDn3OoyCmbqN9VW5gVSsQFtG7r2GiTTZhYJ2Zgq+fu4+QD7mC9FQu+k/8yrLI0ovnBtAdM+RVgDCZjV2y0HNg5nLGM4eHLHj7YR0HK/n6NNzDQGAxVjtSfVhakY+6z7flOhUOBdSurO23AOok8GP6zOq9Hh8ioBa42LxDdoQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=gocR8Mhl; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="gocR8Mhl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1780622216; x=1812158216; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=99LaCPX5v3Uxh5M6N+wcyfmWLe5NRtFKC2Yvy4+Lvjk=; b=gocR8Mhly9nTM0kF7oWyZ0FmjFoEIr3ZDadOZ1pDP1N0TYU1OH9Dpgji I0Gk6vqi+igcHat0duPw4C5tOfuZ9jjlvatP2gozusmg46ITxBkPCBLsO r03sEXFWdYsKVOG0gHPX+AXxnGUME10d2LGvQZfbiawl8iGB6cTJvwg++ ws1NxeyJKB0+4UQhvtf1yyaP9VOgczyNM0DN5hzEfgTqH6F+1/ZFzJoZH mmHZj5iATPHAmnVrjbW7sFo3lrD+29q1YevyVB/GsqygK1zOCf5MvQEx8 flW/7Z8AFwJMZSsIcM04xXXJEm7dsxmfH/06o3OYTeJ7+GiR7Bs8p3WYj w==; X-CSE-ConnectionGUID: 1xIpTgTiTf+RcHDOgxxHqg== X-CSE-MsgGUID: TdJwhkuAT+mgHz03OZ871w== X-IronPort-AV: E=McAfee;i="6800,10657,11807"; a="91772180" X-IronPort-AV: E=Sophos;i="6.24,188,1774335600"; d="scan'208";a="91772180" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jun 2026 18:16:56 -0700 X-CSE-ConnectionGUID: PDfKJrB7QlqKjQPJmhNRpQ== X-CSE-MsgGUID: mJsfoDSzQW+/gwiFuekubQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,188,1774335600"; d="scan'208";a="244817113" Received: from spr.sh.intel.com ([10.112.230.239]) by orviesa007.jf.intel.com with ESMTP; 04 Jun 2026 18:16:53 -0700 From: Dapeng Mi To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Ian Rogers , Adrian Hunter , Alexander Shishkin , Andi Kleen , Eranian Stephane Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Dapeng Mi , Zide Chen , Falcon Thomas , Xudong Hao , Dapeng Mi Subject: [PATCH 2/8] perf/x86: Introduce is_x86_pmu() helper Date: Fri, 5 Jun 2026 09:11:30 +0800 Message-Id: <20260605011136.2043393-3-dapeng1.mi@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260605011136.2043393-1-dapeng1.mi@linux.intel.com> References: <20260605011136.2043393-1-dapeng1.mi@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ian Rogers To facilitate the detection of x86 PMU structures in upcoming patches, the is_x86_pmu() helper is introduced. Additionally, the is_x86_event() helper has been refactored to utilize is_x86_pmu(). No function changes intended. Signed-off-by: Ian Rogers Signed-off-by: Dapeng Mi Reviewed-by: Zide Chen Reviewed-by: Thomas Falcon --- Original patch link: https://lore.kernel.org/all/20260316050838.3624051-1-dapeng1.mi@linux.intel= .com/ arch/x86/events/core.c | 16 ---------------- arch/x86/events/perf_event.h | 18 +++++++++++++++++- 2 files changed, 17 insertions(+), 17 deletions(-) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 4b9e105309c6..3bd0522afe6d 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -774,22 +774,6 @@ void x86_pmu_enable_all(int added) } } =20 -int is_x86_event(struct perf_event *event) -{ - /* - * For a non-hybrid platforms, the type of X86 pmu is - * always PERF_TYPE_RAW. - * For a hybrid platform, the PERF_PMU_CAP_EXTENDED_HW_TYPE - * is a unique capability for the X86 PMU. - * Use them to detect a X86 event. - */ - if (event->pmu->type =3D=3D PERF_TYPE_RAW || - event->pmu->capabilities & PERF_PMU_CAP_EXTENDED_HW_TYPE) - return true; - - return false; -} - struct pmu *x86_get_pmu(unsigned int cpu) { struct cpu_hw_events *cpuc =3D &per_cpu(cpu_hw_events, cpu); diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h index 5902a297daa1..dbb5c8e8a8ea 100644 --- a/arch/x86/events/perf_event.h +++ b/arch/x86/events/perf_event.h @@ -115,7 +115,23 @@ static inline bool is_topdown_event(struct perf_event = *event) return is_metric_event(event) || is_slots_event(event); } =20 -int is_x86_event(struct perf_event *event); +static inline bool is_x86_pmu(struct pmu *pmu) +{ + /* + * For a non-hybrid platforms, the type of X86 pmu is + * always PERF_TYPE_RAW. + * For a hybrid platform, the PERF_PMU_CAP_EXTENDED_HW_TYPE + * is a unique capability for the X86 PMU. + * Use them to detect a X86 event. + */ + return pmu->type =3D=3D PERF_TYPE_RAW || + pmu->capabilities & PERF_PMU_CAP_EXTENDED_HW_TYPE; +} + +static inline bool is_x86_event(struct perf_event *event) +{ + return is_x86_pmu(event->pmu); +} =20 static inline bool check_leader_group(struct perf_event *leader, int flags) { --=20 2.34.1 From nobody Mon Jun 8 07:22:04 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4C62637AA9C; Fri, 5 Jun 2026 01:17:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780622225; cv=none; b=cHlbekGYj1Ns1WFh7iuY+DGqOQExxfQ3zDASwa21Qo8ZAxwa1KO3VNmgpoXcREI7aC1QxOyN529qC6stEEAi+HgHFWTv/c3MRoQfnShKe8QIx6wbDEXPlOgj7QjmFa7HJEES+yPmZvT/acqZovzcK7sP2fhKuVUnnDP3LJ/GiKQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780622225; c=relaxed/simple; bh=CC2Kq79leFFZe4IlLmqlNstv/NPsgz24jysL+MZMAW4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Iv7FWsRH3s+DZPtxNrsioG8+qqFcBFlj7KyZPJJyNJs73kiyhXGV+MdOcaSXyiTFssKhCo73W2fmId8Wk7rHCen+GyBgStHUiHGpC3XpGzkKVHbpm7xO2Bteclo46DtEQyil6k6mQmoHklC8qCTQbmfE6TTeBsuHaEKrQFIOO9E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=a3iunk6u; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="a3iunk6u" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1780622220; x=1812158220; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=CC2Kq79leFFZe4IlLmqlNstv/NPsgz24jysL+MZMAW4=; b=a3iunk6uDxSvHeYt2OTpi5DlnVlhCq/wSn0FNsTi2KQcmsShIOi9NRn4 Ht/q9Csh0CZVFqJTe9KHQBrtBj34duf651nbs2Tkgm9X2Iu2yKvcOdd0T m1d8cqGri2zZlHlxmT2qIPaKi0YfSeCG1zHz8GMFU+vPhyodfu0LVr8R+ Ym5E5e0yZhOvc8FTeP/SlgnWAsBYE3haD7ujTWgYJZCEpH3rBJKhL6I8k 7S0Rbzs45YLCfQitmdubI3ZwLzHZOtE8viIkNFUZ5iW3tqIe0qvr5q0ZG REui0Ii2MKIVbtS2G9N5S7EJnSoo8ol7G5rXZG+Zj287A8h7v1CBjPt0r g==; X-CSE-ConnectionGUID: yfc7S2lsTqW+zHnH9QJOgw== X-CSE-MsgGUID: 233PCDIrSYa94kgeeM7b5g== X-IronPort-AV: E=McAfee;i="6800,10657,11807"; a="91772186" X-IronPort-AV: E=Sophos;i="6.24,188,1774335600"; d="scan'208";a="91772186" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jun 2026 18:17:00 -0700 X-CSE-ConnectionGUID: 5/KWcsjPR0mPe2yVdrebWQ== X-CSE-MsgGUID: +MHGYfW2SImCE5CoR4bhxw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,188,1774335600"; d="scan'208";a="244817117" Received: from spr.sh.intel.com ([10.112.230.239]) by orviesa007.jf.intel.com with ESMTP; 04 Jun 2026 18:16:57 -0700 From: Dapeng Mi To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Ian Rogers , Adrian Hunter , Alexander Shishkin , Andi Kleen , Eranian Stephane Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Dapeng Mi , Zide Chen , Falcon Thomas , Xudong Hao , Dapeng Mi Subject: [PATCH 3/8] perf/x86: Update cap_user_rdpmc base on rdpmc user disable state Date: Fri, 5 Jun 2026 09:11:31 +0800 Message-Id: <20260605011136.2043393-4-dapeng1.mi@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260605011136.2043393-1-dapeng1.mi@linux.intel.com> References: <20260605011136.2043393-1-dapeng1.mi@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" After introducing the RDPMC user disable feature, user-space RDPMC may return 0 instead of the actual event count. This creates an inconsistency with cap_user_rdpmc, where cap_user_rdpmc is set, but user-space RDPMC only returns 0. To accurately represent the user-space RDPMC capability, update cap_user_rdpmc based on the RDPMC user disable state. If RDPMC user disable is enabled, cap_user_rdpmc is set to false, allowing user-space programs to fall back to the read() syscall to obtain the real event count. Since arch_perf_update_userpage() could be called for software events, enhance x86_pmu_has_rdpmc_user_disable() to only check the x86 PMUs. Fixes: 59af95e028d4 ("perf/x86/intel: Add support for rdpmc user disable fe= ature") Signed-off-by: Dapeng Mi Reviewed-by: Zide Chen Reviewed-by: Thomas Falcon --- Original patch link: https://lore.kernel.org/all/20260316050838.3624051-2-dapeng1.mi@linux.intel= .com/ arch/x86/events/core.c | 3 +++ arch/x86/events/perf_event.h | 5 +++-- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 3bd0522afe6d..6cd95b8e31cb 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -2797,6 +2797,9 @@ void arch_perf_update_userpage(struct perf_event *eve= nt, userpg->cap_user_time_zero =3D 0; userpg->cap_user_rdpmc =3D !!(event->hw.flags & PERF_EVENT_FLAG_USER_READ_CNT); + if (x86_pmu_has_rdpmc_user_disable(event->pmu) && + event->hw.config & ARCH_PERFMON_EVENTSEL_RDPMC_USER_DISABLE) + userpg->cap_user_rdpmc =3D 0; userpg->pmc_width =3D x86_pmu.cntval_bits; =20 if (!using_native_sched_clock() || !sched_clock_stable()) diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h index dbb5c8e8a8ea..4003e2e0aa9c 100644 --- a/arch/x86/events/perf_event.h +++ b/arch/x86/events/perf_event.h @@ -1359,8 +1359,9 @@ static inline u64 x86_pmu_get_event_config(struct per= f_event *event) =20 static inline bool x86_pmu_has_rdpmc_user_disable(struct pmu *pmu) { - return !!(hybrid(pmu, config_mask) & - ARCH_PERFMON_EVENTSEL_RDPMC_USER_DISABLE); + return is_x86_pmu(pmu) && + (hybrid(pmu, config_mask) & + ARCH_PERFMON_EVENTSEL_RDPMC_USER_DISABLE); } =20 extern struct event_constraint emptyconstraint; --=20 2.34.1 From nobody Mon Jun 8 07:22:04 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 90FEB37D135; Fri, 5 Jun 2026 01:17:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780622229; cv=none; b=Y6ZItHq/fmcebfubWUlIEvNEP0UdzvbZx0/vtlDOExrPgylXDW2KnajN5UxJSI/UKRDBTf/CJuM8nHabJCGVTbQ6D89ipv1wQnG7iBTuKe9G0gzhlIVOVXqsNimPxO9lgdkO/oITJeAUc0Fzb4L2KfGOyRE7FaUnW8QDIVRpAvU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780622229; c=relaxed/simple; bh=mM9Pr8lZ3nTTBIy6EC6BHzVoL0MBKDOZfyc0JGyxsaQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=TTXr28zDIIySZGzLJ7/pmHp1ZvAxZX3d+IcUcbEzby0cGat8nkJxa2cx7P87ZDbYATaKc9AKTIkwyeMkyN2T9wGMC5AkhTWohrZejQPmYMZXkglpL6BqoiJYJmtRHYPBlZZDWhhoLTlOf97M2J5HP2Hni3paDEQl8JWlaLB1+uA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=KJavDAK5; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="KJavDAK5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1780622224; x=1812158224; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=mM9Pr8lZ3nTTBIy6EC6BHzVoL0MBKDOZfyc0JGyxsaQ=; b=KJavDAK5Qnr5Xl28Md+Vx2Vq3O2qutRjGrCZR8ygfIwmlk1gNFVIcY1v 1TCaOcc1A1/Qrc6qDkusl5Hu20LfA2Ls5iQJog//htjAbk7XpX+PV7XiQ UVIj82AFdHF5c/4AjYsQ9oV+S1LYmDYXqoGeFc7hib+Tv6TZecgHSgq9V XGNw4dakb2ACstAqLXdbjnCuD/yFdx6J4JS1oor5zxZnQ8ty9APyc623U d4EzWtqvMSQc0gnOlQ+pLv0lWpQV1g/snLRCppRqXpoW55gOy3ephr2E3 DpKJrVmBRqLgNeEdT1N5ctdX0t9woCMavuoFMvejJty9hb9ZgIWXTRVj9 A==; X-CSE-ConnectionGUID: 4pTuYWYdSaeTQzB68l6VQA== X-CSE-MsgGUID: EYHGe2/fSs2uUtxnEVU3jg== X-IronPort-AV: E=McAfee;i="6800,10657,11807"; a="91772193" X-IronPort-AV: E=Sophos;i="6.24,188,1774335600"; d="scan'208";a="91772193" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jun 2026 18:17:04 -0700 X-CSE-ConnectionGUID: 3VAqbbqQQ/y3fHUdgJuUdQ== X-CSE-MsgGUID: zhh635Q9RGm8rq8RXowFXQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,188,1774335600"; d="scan'208";a="244817125" Received: from spr.sh.intel.com ([10.112.230.239]) by orviesa007.jf.intel.com with ESMTP; 04 Jun 2026 18:17:01 -0700 From: Dapeng Mi To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Ian Rogers , Adrian Hunter , Alexander Shishkin , Andi Kleen , Eranian Stephane Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Dapeng Mi , Zide Chen , Falcon Thomas , Xudong Hao , Dapeng Mi , stable@vger.kernel.org Subject: [PATCH 4/8] perf/x86/intel: Fix redundant branch type check in intel_pmu_lbr_filter() Date: Fri, 5 Jun 2026 09:11:32 +0800 Message-Id: <20260605011136.2043393-5-dapeng1.mi@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260605011136.2043393-1-dapeng1.mi@linux.intel.com> References: <20260605011136.2043393-1-dapeng1.mi@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" In intel_pmu_lbr_filter(), the 'type' variable is bitwise ORed with 'to_plm' (which contains X86_BR_USER and/or X86_BR_KERNEL bits). Because of this, 'type' can never equal X86_BR_NONE (0) after the assignment. As a result, the subsequent check 'if (type =3D=3D X86_BR_NONE)' is dead co= de and the entries with X86_BR_NONE type would not be skipped eventually. Correct this by masking out the X86_BR_KERNEL and X86_BR_USER bits before performing the X86_BR_NONE comparison. Cc: stable@vger.kernel.org Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR") Signed-off-by: Dapeng Mi --- Original patch link: https://lore.kernel.org/all/20260414021440.928068-1-dapeng1.mi@linux.intel.= com/ arch/x86/events/intel/lbr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c index 72f2adcda7c6..16977e4c6f8a 100644 --- a/arch/x86/events/intel/lbr.c +++ b/arch/x86/events/intel/lbr.c @@ -1245,7 +1245,7 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc) } =20 /* if type does not correspond, then discard */ - if (type =3D=3D X86_BR_NONE || (br_sel & type) !=3D type) { + if ((type & ~X86_BR_PLM) =3D=3D X86_BR_NONE || (br_sel & type) !=3D type= ) { cpuc->lbr_entries[i].from =3D 0; compress =3D true; } --=20 2.34.1 From nobody Mon Jun 8 07:22:04 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C79E5302146; Fri, 5 Jun 2026 01:17:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780622235; cv=none; b=BEZmSSmLtCWYVJNy9zMoEIJ3sF9lOrbwFTTPG6o9azm62b3edYLc+P7Hg1vEN5dPLNUjtijcypsXSV5yEo6SVLHDq4uN39/l1yiKPllt84+RJLVG9OJdq1fMjG1++PdSPEopQMNPk2P2UIbPsvTIHTHUmEQNNK7HOoKNl+WQrOI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780622235; c=relaxed/simple; bh=1xqqepDK/sIzH2p5f3vcymeZZbvqnGrqr53wGsDaiTw=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=E6RMOJszwMwmnjVtBAS0AIiLLZ5h2Z7dy82rKPWFWIegVcFqAn9dZTsQgNqxVbt7RT8JOm+xKJ59NJ/4/n+Jzctm++AAHglfYEX5FhSYP3FUjg94ywJ2cL4UXyyrjN60HfaOfZ/2XK3i06eicrNbO9RteV1R6GBLgjATQLuSQMA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=MC7o1w2L; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="MC7o1w2L" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1780622228; x=1812158228; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=1xqqepDK/sIzH2p5f3vcymeZZbvqnGrqr53wGsDaiTw=; b=MC7o1w2LOoEmFLBwf2vo0TDjMQ/LKm2P3pSZWWYzAycfac6k6jKchbGK vbFpno4XaMEzP5z7nWbqPqZ7ZXpvbaHtqu5Gz/3dZL4phxKM9eInYr8rp PJ4Bzd9d2BJUe0ONA+MOfK2tcODO6y26Lu3DG4s+eLheE+SnFcWxxfDxJ wxWBBtKGv3odGKLlg2Qq/Tun/ezLggo4yuHhT+EslbkH3+5CgZYiVM9Ks XFZptMZWmwss+nhet4eo64YG6P+X1HvHB4TNbisAW2pGg95ZX4NDrC+I+ HTYqHMyQoFoaiDog05GE11Xa+7EGzmTZp8SvXYblOkqLJvpfKyO5pCOKr Q==; X-CSE-ConnectionGUID: O4wxLnSkR++9yGB2LpItUw== X-CSE-MsgGUID: kCMEcLvnSEi+RhFBeKSbbw== X-IronPort-AV: E=McAfee;i="6800,10657,11807"; a="91772201" X-IronPort-AV: E=Sophos;i="6.24,188,1774335600"; d="scan'208";a="91772201" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jun 2026 18:17:08 -0700 X-CSE-ConnectionGUID: 3MFOZ9QzTWySCH9yKOVj0Q== X-CSE-MsgGUID: B07lG1+ATQeREm96OaDDtw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,188,1774335600"; d="scan'208";a="244817129" Received: from spr.sh.intel.com ([10.112.230.239]) by orviesa007.jf.intel.com with ESMTP; 04 Jun 2026 18:17:05 -0700 From: Dapeng Mi To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Ian Rogers , Adrian Hunter , Alexander Shishkin , Andi Kleen , Eranian Stephane Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Dapeng Mi , Zide Chen , Falcon Thomas , Xudong Hao , Dapeng Mi , stable@vger.kernel.org Subject: [PATCH 5/8] perf/x86/intel: Fix kernel address leakages in LBR stack Date: Fri, 5 Jun 2026 09:11:33 +0800 Message-Id: <20260605011136.2043393-6-dapeng1.mi@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260605011136.2043393-1-dapeng1.mi@linux.intel.com> References: <20260605011136.2043393-1-dapeng1.mi@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Prior to the arch-LBR which supports CPL filtering, the kernel address could be leaked to user space even PERF_SAMPLE_BRANCH_USER is required. e.g., run below command on Intel Tigerlake platform, ``` $./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \ ./perf bench syscall basic --loop 1000 | \ ./perf script -i - --fields brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- ``` The SYSRET/ERET branch calls are found the in the LBR stack, whose "from" addresses are obviously kernel address. Currently intel_pmu_lbr_filter() only filters out the LBR entries whose "to" address is a kernel address but doesn't check the "from" address. To fix the issue, extend the software filtering to both "from" and "to" addresses. Cc: stable@vger.kernel.org Reported-by: Ian Rogers Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR") Signed-off-by: Dapeng Mi --- Original patch link: https://lore.kernel.org/all/20260414021440.928068-2-dapeng1.mi@linux.intel.= com/ arch/x86/events/intel/lbr.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c index 16977e4c6f8a..deef81c16571 100644 --- a/arch/x86/events/intel/lbr.c +++ b/arch/x86/events/intel/lbr.c @@ -1212,7 +1212,7 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc) { u64 from, to; int br_sel =3D cpuc->br_sel; - int i, j, type, to_plm; + int i, j, type, to_plm, from_plm; bool compress =3D false; =20 /* if sampling all branches, then nothing to filter */ @@ -1244,8 +1244,15 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc) type |=3D X86_BR_NO_TX; } =20 - /* if type does not correspond, then discard */ - if ((type & ~X86_BR_PLM) =3D=3D X86_BR_NONE || (br_sel & type) !=3D type= ) { + from_plm =3D kernel_ip(from) ? X86_BR_KERNEL : X86_BR_USER; + /* + * If type does not correspond, then discard. + * Especially filter out the entries whose from or to address + * is a kernel address while only X86_BR_USER is set. This prevents + * kernel address from being leaked into a user-space-only LBR stack. + */ + if ((type & ~X86_BR_PLM) =3D=3D X86_BR_NONE || (br_sel & type) !=3D type= || + (!(br_sel & X86_BR_KERNEL) && (from_plm & X86_BR_KERNEL))) { cpuc->lbr_entries[i].from =3D 0; compress =3D true; } --=20 2.34.1 From nobody Mon Jun 8 07:22:04 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C87FD37EFF3; Fri, 5 Jun 2026 01:17:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780622239; cv=none; b=e/KzTr3gYUl2os4TyQJkQRgoIJYV9ds8lUuWu70Xqv48dGqdbFtlZM9Rv02j4tWcuextS0sLwCJOtRhG2bO2icvxdGdz0Q+npKb3ahxPAi+AlQ+SwIAAnQCcUW5VZepYRbFnfk3mPGEqVhHtZn2JsoDkt0ACTmdyVKnu26KDBQ4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780622239; c=relaxed/simple; bh=WrUtAFx8/uOHsgsK07WglPn33LI2BwUxZ7QyWPPnFMA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=kRhsNR6VOMKDeI2K6LrFQHiAuMdh9dL9VljSWzgHdJC/efcRyQHK0tKR5/lZFt4kByIb9hTSsSvDOKZm3asGQh6yJLZcaxoNiTcTfEbCHjFM6gpBdEI08xF/2GNGPs5RLlipyi0ynsLGChrjsocxpg6iksxe9jlvwoz3tB9mcb8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=n/Mu4IH2; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="n/Mu4IH2" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1780622232; x=1812158232; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=WrUtAFx8/uOHsgsK07WglPn33LI2BwUxZ7QyWPPnFMA=; b=n/Mu4IH2Cu6FqDRfpVZqGVfRzQKYADIz1V9bgR3ZGEDPBfnm9ndOEkGt ZQ2JTSs4fVz3JxV2jIedU0RZIn9KO26B4OLNDOl2aEG2rpZlemxlcNu5u uJiiPLCspAj8a2LRLEyzCyGrNBTn8G/LmopFT6a4ib+neDDUmRlUoqBRZ aUKYItxap1iHdjg/Y+yHFXjkuGNVTQhrc8A1kSrZcZcrdKWfh15D18Mel Avh229IajiJGPCKD5o4LkDCTVLfp2bPwOD9V2BCzxRhjqx0NmH+uaZ3dy wSwk598kghyDxtw+Y3x5N8TSWxwGrHacOyzf5Z2dj/qRT7cGlRvsPraNn g==; X-CSE-ConnectionGUID: 7mnnJ39zQDOjFHws6HkNpA== X-CSE-MsgGUID: Hm+lI5viQhieFab69RMLCA== X-IronPort-AV: E=McAfee;i="6800,10657,11807"; a="91772207" X-IronPort-AV: E=Sophos;i="6.24,188,1774335600"; d="scan'208";a="91772207" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jun 2026 18:17:12 -0700 X-CSE-ConnectionGUID: tt3sTSfFRA6Zi13MncHr4w== X-CSE-MsgGUID: 537LBN0xRCSVmgszAB9aFw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,188,1774335600"; d="scan'208";a="244817134" Received: from spr.sh.intel.com ([10.112.230.239]) by orviesa007.jf.intel.com with ESMTP; 04 Jun 2026 18:17:09 -0700 From: Dapeng Mi To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Ian Rogers , Adrian Hunter , Alexander Shishkin , Andi Kleen , Eranian Stephane Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Dapeng Mi , Zide Chen , Falcon Thomas , Xudong Hao , Dapeng Mi Subject: [PATCH 6/8] perf/x86/intel: Validate return value of intel_pmu_init_hybrid() Date: Fri, 5 Jun 2026 09:11:34 +0800 Message-Id: <20260605011136.2043393-7-dapeng1.mi@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260605011136.2043393-1-dapeng1.mi@linux.intel.com> References: <20260605011136.2043393-1-dapeng1.mi@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The memory allocation for the x86_pmu.hybrid_pmu[] array in intel_pmu_init_hybrid() can theoretically fail due to memory shortages. If this occurs, the initialization of the x86 hybrid PMU would fail. Currently, the code does not check the return value of the intel_pmu_init_hybrid() function, which could lead to attempts to access the uninitialized x86_pmu.hybrid_pmu[] array, potentially causing a system panic. So, adds a check for the return value of intel_pmu_init_hybrid() to prevent invalid memory access in such scenarios. Besides, free the created kmem cache when error occurs. Signed-off-by: Dapeng Mi Reviewed-by: Thomas Falcon Reviewed-by: Zide Chen --- arch/x86/events/intel/core.c | 33 ++++++++++++++++++++++++++------- 1 file changed, 26 insertions(+), 7 deletions(-) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index ea3ab3050a3b..efd9caa3502c 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -7870,6 +7870,7 @@ __init int intel_pmu_init(void) int version, i; char *name; struct x86_hybrid_pmu *pmu; + int ret; =20 /* Architectural Perfmon was introduced starting with Core "Yonah" */ if (!cpu_has(&boot_cpu_data, X86_FEATURE_ARCH_PERFMON)) { @@ -8539,7 +8540,9 @@ __init int intel_pmu_init(void) * * Initialize the common PerfMon capabilities here. */ - intel_pmu_init_hybrid(hybrid_big_small); + ret =3D intel_pmu_init_hybrid(hybrid_big_small); + if (ret < 0) + goto err; =20 x86_pmu.pebs_latency_data =3D grt_latency_data; x86_pmu.get_event_constraints =3D adl_get_event_constraints; @@ -8597,7 +8600,9 @@ __init int intel_pmu_init(void) case INTEL_METEORLAKE: case INTEL_METEORLAKE_L: case INTEL_ARROWLAKE_U: - intel_pmu_init_hybrid(hybrid_big_small); + ret =3D intel_pmu_init_hybrid(hybrid_big_small); + if (ret < 0) + goto err; =20 x86_pmu.pebs_latency_data =3D cmt_latency_data; x86_pmu.get_event_constraints =3D mtl_get_event_constraints; @@ -8628,7 +8633,9 @@ __init int intel_pmu_init(void) pr_cont("Pantherlake Hybrid events, "); name =3D "pantherlake_hybrid"; =20 - intel_pmu_init_hybrid(hybrid_big_small); + ret =3D intel_pmu_init_hybrid(hybrid_big_small); + if (ret < 0) + goto err; =20 /* Initialize big core specific PerfMon capabilities.*/ pmu =3D &x86_pmu.hybrid_pmu[X86_HYBRID_PMU_CORE_IDX]; @@ -8643,7 +8650,9 @@ __init int intel_pmu_init(void) pr_cont("Arrowlake Hybrid events, "); name =3D "arrowlake_hybrid"; =20 - intel_pmu_init_hybrid(hybrid_big_small); + ret =3D intel_pmu_init_hybrid(hybrid_big_small); + if (ret < 0) + goto err; =20 /* Initialize big core specific PerfMon capabilities.*/ pmu =3D &x86_pmu.hybrid_pmu[X86_HYBRID_PMU_CORE_IDX]; @@ -8660,7 +8669,9 @@ __init int intel_pmu_init(void) pr_cont("Lunarlake Hybrid events, "); name =3D "lunarlake_hybrid"; =20 - intel_pmu_init_hybrid(hybrid_big_small); + ret =3D intel_pmu_init_hybrid(hybrid_big_small); + if (ret < 0) + goto err; =20 /* Initialize big core specific PerfMon capabilities.*/ pmu =3D &x86_pmu.hybrid_pmu[X86_HYBRID_PMU_CORE_IDX]; @@ -8685,7 +8696,9 @@ __init int intel_pmu_init(void) break; =20 case INTEL_ARROWLAKE_H: - intel_pmu_init_hybrid(hybrid_big_small_tiny); + ret =3D intel_pmu_init_hybrid(hybrid_big_small_tiny); + if (ret < 0) + goto err; =20 x86_pmu.pebs_latency_data =3D arl_h_latency_data; x86_pmu.get_event_constraints =3D arl_h_get_event_constraints; @@ -8720,7 +8733,9 @@ __init int intel_pmu_init(void) case INTEL_NOVALAKE_L: pr_cont("Novalake Hybrid events, "); name =3D "novalake_hybrid"; - intel_pmu_init_hybrid(hybrid_big_small); + ret =3D intel_pmu_init_hybrid(hybrid_big_small); + if (ret < 0) + goto err; =20 x86_pmu.pebs_latency_data =3D nvl_latency_data; x86_pmu.get_event_constraints =3D mtl_get_event_constraints; @@ -8885,6 +8900,10 @@ __init int intel_pmu_init(void) intel_aux_output_init(); =20 return 0; + +err: + kmem_cache_destroy(x86_get_pmu(smp_processor_id())->task_ctx_cache); + return ret; } =20 /* --=20 2.34.1 From nobody Mon Jun 8 07:22:04 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 24A2636D503; Fri, 5 Jun 2026 01:17:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780622243; cv=none; b=ftz+2lqyt2tc27Pgi60wPDeSKVIfrXwEklyxLYRHinUHTKxHUj0YsPAQkovFaEN7KTYuuDmkgwvUu4Fe9omkwKeH4A4ADX+QPe7ZTFpYbbGZzDiTmH6g5sHxzBGm0CO6jz/cDOoYb3BnUHtrBejppiHH5sLZwxviVRYkfW44iAc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780622243; c=relaxed/simple; bh=d9C2tn7l7TBWtBWscp2bFWf2Su8H/WG01jblldosi9I=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=rYQEDT64b6Soq36eIyOOibSqt5n6gFp0rw4dBk5A4amps2hknkxRBKLxllq/RnIBAvJPDYk9xkp/Iq3pKxgWnt/XkxWS4kz5A8WuGne3IcJJlPH2QH+WCkdX0NYDf+7AroxhMZECxnFLYMey07AfsmnFHwhRqTwd80S+u1w1z/Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=VPg8Gpmq; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="VPg8Gpmq" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1780622237; x=1812158237; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=d9C2tn7l7TBWtBWscp2bFWf2Su8H/WG01jblldosi9I=; b=VPg8GpmqmNq8llkFPlzwdQMTqkvelORc8Us3eO0tLFBluFD7I4jeKkmj PAUhg8PEqMbyTSxsLmpM0SXiDV6WJHgH8t/Mq5PiZEfkzuQYCsHCuqCZf anbH0ohOi54XwafQJTv/C0xndcKCyDPm8y8bcZwhFb7rq4+O85NuCAdkP l76VX4eyOL1Ja4DK2bGtiNnHRTx2Q1jXV0vrTt/z8RAuSB17TpHtUk/Qw TjMUKzeIyJ9x8hhOyPB+NdHLUc13PSk4gD6Hy6sKnHDxi++xZoCFgSF6s PcAqZvEDNrgNYkoSLXzdROlWi1w7kotYDr2p3g4dIdL6E/MFrspnr1fe3 g==; X-CSE-ConnectionGUID: DIzXqmfkTLiliSL6JCsPrQ== X-CSE-MsgGUID: wIvn/tOwSMa01M+oqJWC/Q== X-IronPort-AV: E=McAfee;i="6800,10657,11807"; a="91772213" X-IronPort-AV: E=Sophos;i="6.24,188,1774335600"; d="scan'208";a="91772213" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jun 2026 18:17:16 -0700 X-CSE-ConnectionGUID: lJ/qi7pzTHqOdI7qfLU6aw== X-CSE-MsgGUID: xK01CeQFTGiPTFvxy4FOQQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,188,1774335600"; d="scan'208";a="244817163" Received: from spr.sh.intel.com ([10.112.230.239]) by orviesa007.jf.intel.com with ESMTP; 04 Jun 2026 18:17:13 -0700 From: Dapeng Mi To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Ian Rogers , Adrian Hunter , Alexander Shishkin , Andi Kleen , Eranian Stephane Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Dapeng Mi , Zide Chen , Falcon Thomas , Xudong Hao , Dapeng Mi , Yi Lai Subject: [PATCH 7/8] perf/x86/intel: Drop fixed-counter PEBS constraints for baseline PEBS Date: Fri, 5 Jun 2026 09:11:35 +0800 Message-Id: <20260605011136.2043393-8-dapeng1.mi@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260605011136.2043393-1-dapeng1.mi@linux.intel.com> References: <20260605011136.2043393-1-dapeng1.mi@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On SPR guests where pebs_baseline is not advertised, running: $ ./perf record -e cpu/event=3D0x00,umask=3D0x01,i\ name=3DINST_RETIRED.PREC_DIST/p -c 10000 sleep 1 can trigger: unchecked MSR access error: WRMSR to 0x3f1 ... in\ intel_pmu_pebs_enable_all() Root cause: SPR-specific PEBS constraints allow fixed-counter scheduling, for example INST_RETIRED.PREC_DIST on fixed counter 0. In guests without pebs_baseline, KVM does not support PEBS sampling on fixed counters, so enabling such events reaches an invalid MSR programming path. Fix: Drop fixed-counter entries from the PEBS constraint table. Without pebs_baseline, those fixed-counter PEBS events now resolve to empty constraints and are not scheduled/enabled, avoiding the warning and the broken guest PEBS path. This is safe because, in pebs_baseline-capable cases, PEBS constraint lookup already falls back to non-PEBS constraints when needed, and fixed-counter constraints are effectively shared there. Reported-by: Yi Lai Signed-off-by: Dapeng Mi --- arch/x86/events/intel/ds.c | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c index cb72af9b61ce..5db15a92017a 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -1447,10 +1447,6 @@ struct event_constraint intel_skl_pebs_event_constra= ints[] =3D { }; =20 struct event_constraint intel_icl_pebs_event_constraints[] =3D { - INTEL_FLAGS_UEVENT_CONSTRAINT(0x01c0, 0x100000000ULL), /* old INST_RETIRE= D.PREC_DIST */ - INTEL_FLAGS_UEVENT_CONSTRAINT(0x0100, 0x100000000ULL), /* INST_RETIRED.PR= EC_DIST */ - INTEL_FLAGS_UEVENT_CONSTRAINT(0x0400, 0x800000000ULL), /* SLOTS */ - INTEL_PLD_CONSTRAINT(0x1cd, 0xff), /* MEM_TRANS_RETIRED.LOAD_LATENCY */ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_LD(0x11d0, 0xf), /* MEM_INST_RETIRED= .STLB_MISS_LOADS */ INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_ST(0x12d0, 0xf), /* MEM_INST_RETIRED= .STLB_MISS_STORES */ @@ -1473,9 +1469,6 @@ struct event_constraint intel_icl_pebs_event_constrai= nts[] =3D { }; =20 struct event_constraint intel_glc_pebs_event_constraints[] =3D { - INTEL_FLAGS_UEVENT_CONSTRAINT(0x100, 0x100000000ULL), /* INST_RETIRED.PRE= C_DIST */ - INTEL_FLAGS_UEVENT_CONSTRAINT(0x0400, 0x800000000ULL), - INTEL_FLAGS_EVENT_CONSTRAINT(0xc0, 0xfe), INTEL_PLD_CONSTRAINT(0x1cd, 0xfe), INTEL_PSD_CONSTRAINT(0x2cd, 0x1), @@ -1500,9 +1493,6 @@ struct event_constraint intel_glc_pebs_event_constrai= nts[] =3D { }; =20 struct event_constraint intel_lnc_pebs_event_constraints[] =3D { - INTEL_FLAGS_UEVENT_CONSTRAINT(0x100, 0x100000000ULL), /* INST_RETIRED.PRE= C_DIST */ - INTEL_FLAGS_UEVENT_CONSTRAINT(0x0400, 0x800000000ULL), - INTEL_FLAGS_UEVENT_CONSTRAINT(0x012a, 0x1), /* OCR.* events */ INTEL_FLAGS_UEVENT_CONSTRAINT(0x012b, 0x1), /* OCR.* events */ =20 @@ -1534,9 +1524,6 @@ struct event_constraint intel_lnc_pebs_event_constrai= nts[] =3D { }; =20 struct event_constraint intel_pnc_pebs_event_constraints[] =3D { - INTEL_FLAGS_UEVENT_CONSTRAINT(0x100, 0x100000000ULL), /* INST_RETIRED.PRE= C_DIST */ - INTEL_FLAGS_UEVENT_CONSTRAINT(0x0400, 0x800000000ULL), - INTEL_HYBRID_LDLAT_CONSTRAINT(0x1cd, 0xfc), INTEL_HYBRID_STLAT_CONSTRAINT(0x2cd, 0x3), INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_LD(0x11d0, 0xf), /* MEM_INST_RETIRED= .STLB_MISS_LOADS */ --=20 2.34.1 From nobody Mon Jun 8 07:22:04 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 49DF829AAFA; Fri, 5 Jun 2026 01:17:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780622248; cv=none; b=qmKAzozOi+Fu3egL8LVbUrOpbKqPbZYjWlCL3MEQT52HhU8b0Hf/nkyvhO1OQBXh2qAscfd55DFcXpPs61WneoEBjOAX6OxBnJBixqXcaPn971CH50dkLAcqbe3Z2P43Q3jx3mxfjoGjNY9n9SJXi9NfsoNbEZu8tuUmCyuOECw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780622248; c=relaxed/simple; bh=9X8yih0lHJ0Q4enducM9KHyJS3Y1kIDRkX+4U85O9RE=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=p8Liyvp8UcNCJegfobFcK9eut4YmHnsqMdsup15wILI+HpdODuUbh8c0s4BivdSCe8C6JahYgHkF12wVVFyLJJvN9MdCV9EVsHn4pD+khRpwdqvIPH5LS/iJP9ji0S98Bmk7wo487XVJusxT8Vy+yP3WnkEMB2yGyamxU2si4Wc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=GlzBDxaz; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="GlzBDxaz" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1780622241; x=1812158241; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=9X8yih0lHJ0Q4enducM9KHyJS3Y1kIDRkX+4U85O9RE=; b=GlzBDxazpqv7wQ1W1bLSD4axCQcKTsvijEkFI0jg+SCtTKSSbuP6hVuH nh67OExjhfsqCkJadSHgM+6JvzAO4xYRHd8Uz/b9iNopBfdBhuzeJfaUx WSbtRJstgbEsAQIVgkgB8C+6VFtZfO9eFFoPScj49f6wLyaZay+7wx/rn mJy6bqcAQdcgMAauEXvX98DWUKBFlTq6yY8qFsu33GK5VvOg0wrhTlEGP tYdrKRaTu0nEsM3389HUM1eAstgzfkwlmmWqhBuhYh5geS7vJtFWqWtN6 mcVhrdbl6zLc4UcKpf3xsHQhNQLBu9QMpLHGkIASbAEJf+RnGIftcPwnH Q==; X-CSE-ConnectionGUID: Yerv4Po+SWGFQCR5pnrRqw== X-CSE-MsgGUID: 7gK96AJhTiubBG1gGdxyJg== X-IronPort-AV: E=McAfee;i="6800,10657,11807"; a="91772221" X-IronPort-AV: E=Sophos;i="6.24,188,1774335600"; d="scan'208";a="91772221" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jun 2026 18:17:21 -0700 X-CSE-ConnectionGUID: HPUjgi7DSQSOtaSYVqd4qg== X-CSE-MsgGUID: QyXBovdlRAqdVOrVUaQUvQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,188,1774335600"; d="scan'208";a="244817167" Received: from spr.sh.intel.com ([10.112.230.239]) by orviesa007.jf.intel.com with ESMTP; 04 Jun 2026 18:17:18 -0700 From: Dapeng Mi To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Ian Rogers , Adrian Hunter , Alexander Shishkin , Andi Kleen , Eranian Stephane Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Dapeng Mi , Zide Chen , Falcon Thomas , Xudong Hao , Dapeng Mi , Mark Rutland Subject: [PATCH 8/8] perf/core: Fix kernel register info leak via hardware skid Date: Fri, 5 Jun 2026 09:11:36 +0800 Message-Id: <20260605011136.2043393-9-dapeng1.mi@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260605011136.2043393-1-dapeng1.mi@linux.intel.com> References: <20260605011136.2043393-1-dapeng1.mi@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" An unprivileged hardware perf event using exclude_kernel=3D1 can leak kernel register data to user space via PERF_SAMPLE_REGS_INTR. Due to hardware skid, a PMI may trigger after the CPU has already entered kernel space (Ring 0), bypassing the perf_allow_kernel() privilege barrier. This security vulnerability is severely exacerbated by upcoming support for SIMD register sampling via XSAVES, which could expose sensitive kernel FPU states (such as active cryptographic keys). Fix this by ensuring that sampled register data is dropped if the event's exclude_kernel attribute is set but the PMI catches the CPU in kernel mode. Link: https://lore.kernel.org/all/20260529085613.CCAFB1F00893@smtp.kernel.o= rg/ Cc: Peter Zijlstra Cc: Mark Rutland Signed-off-by: Dapeng Mi Reviewed-by: Thomas Falcon --- kernel/events/core.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index 7935d5663944..b7326bc3acd0 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -7800,10 +7800,21 @@ static void perf_sample_regs_user(struct perf_regs = *regs_user, } =20 static void perf_sample_regs_intr(struct perf_regs *regs_intr, - struct pt_regs *regs) + struct pt_regs *regs, + bool exclude_kernel) { - regs_intr->regs =3D regs; - regs_intr->abi =3D perf_reg_abi(current); + /* + * Hardware skid can lead to PMI is delivered after + * the CPU has already entered kernel mode. In that case, + * user-space sampling must not expose kernel register state. + */ + if (exclude_kernel && !user_mode(regs)) { + regs_intr->abi =3D PERF_SAMPLE_REGS_ABI_NONE; + regs_intr->regs =3D NULL; + } else { + regs_intr->regs =3D regs; + regs_intr->abi =3D perf_reg_abi(current); + } } =20 =20 @@ -8694,7 +8705,8 @@ void perf_prepare_sample(struct perf_sample_data *dat= a, /* regs dump ABI info */ int size =3D sizeof(u64); =20 - perf_sample_regs_intr(&data->regs_intr, regs); + perf_sample_regs_intr(&data->regs_intr, regs, + event->attr.exclude_kernel); =20 if (data->regs_intr.regs) { u64 mask =3D event->attr.sample_regs_intr; --=20 2.34.1