[Patch v3 1/8] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities

[Patch v3 1/8] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities

[Dapeng Mi]

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 <namhyung@kernel.org>
Fixes: cadbaa039b99 ("perf/x86/intel: Make anythread filter support conditional")
Acked-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Reviewed-by: Zide Chen <zide.chen@intel.com>
Reviewed-by: Thomas Falcon <thomas.falcon@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)
 
 	x86_add_quirk(intel_arch_events_quirk); /* Install first, so it runs last */
 
-	if (version >= 5) {
-		x86_pmu.intel_cap.anythread_deprecated = edx.split.anythread_deprecated;
-		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 |= PERF_PMU_CAP_MEDIATED_VPMU;
 
@@ -8828,8 +8822,10 @@ __init int intel_pmu_init(void)
 				      &x86_pmu.intel_ctrl);
 
 	/* AnyThread may be deprecated on arch perfmon v5 or later */
-	if (x86_pmu.intel_cap.anythread_deprecated)
+	if (version >= 5 && edx.split.anythread_deprecated) {
 		x86_pmu.format_attrs = intel_arch_formats_attr;
+		pr_cont("AnyThread deprecated, ");
+	}
 
 	intel_pmu_check_event_constraints_all(NULL);
 
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;
-- 
2.34.1

Re: [Patch v3 1/8] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities

[Peter Zijlstra]

On Fri, Jun 12, 2026 at 05:01:07PM +0800, Dapeng Mi wrote:
> 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.

Again, no markdown please. I've stripped it from these patches.

Re: [Patch v3 1/8] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities

[Mi, Dapeng]

On 6/12/2026 5:46 PM, Peter Zijlstra wrote:
> On Fri, Jun 12, 2026 at 05:01:07PM +0800, Dapeng Mi wrote:
>> 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.
> Again, no markdown please. I've stripped it from these patches.

My bad. Thanks a lot.

BTW, Peter, have you pull these patches? I didn't see them in perf/core or
perf/urgent branches. Sashiko reports a defect about "Patch 5/8:
perf/x86/intel: Validate the return value of intel_pmu_init_hybrid()". If
not, I would post a v4 patchset to fix the defect. Thanks.

Re: [Patch v3 1/8] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities

[Mi, Dapeng]

On 6/15/2026 8:59 AM, Mi, Dapeng wrote:
> On 6/12/2026 5:46 PM, Peter Zijlstra wrote:
>> On Fri, Jun 12, 2026 at 05:01:07PM +0800, Dapeng Mi wrote:
>>> 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.
>> Again, no markdown please. I've stripped it from these patches.
> My bad. Thanks a lot.
>
> BTW, Peter, have you pull these patches? I didn't see them in perf/core or
> perf/urgent branches. Sashiko reports a defect about "Patch 5/8:
> perf/x86/intel: Validate the return value of intel_pmu_init_hybrid()". If
> not, I would post a v4 patchset to fix the defect. Thanks.

Just found the patches are merged into the perf/core branch in peterz/queue
tree. :)

Peter, Sashiko raises below concern against the patch 5/8: "perf/x86/intel:
Validate the return value of intel_pmu_init_hybrid()",

"

[Severity: Medium]
Does moving intel_pmu_arch_lbr_init() below
intel_pmu_check_event_constraints_all() bypass the dynamic constraint
validation for branch counters?

When intel_pmu_check_event_constraints_all() runs, it eventually calls
intel_pmu_check_dyn_constr(). This check relies on the PMU_FL_BR_CNTR flag
and the x86_pmu.lbr_counters mask:

arch/x86/events/intel/core.c:intel_pmu_check_dyn_constr() {
    ...
        case DYN_CONSTR_BR_CNTR:
            if (x86_pmu.flags & PMU_FL_BR_CNTR)
                mask = x86_pmu.lbr_counters;
            break;
    ...
}

Because intel_pmu_arch_lbr_init() is now deferred until after this validation,
the PMU_FL_BR_CNTR flag hasn't been set yet. Will this cause the dynamic
constraint check for branch counters to evaluate to false and be skipped?

"

It's a true defect. We need below changes to fix the defect. Would you
prefer to post a new patchset or just a single patch to fix the defect? Thanks.

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 74dbf24b0ab6..edf6f8732234 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -8840,11 +8840,11 @@ __init int intel_pmu_init(void)
                pr_cont("AnyThread deprecated, ");
        }

-       intel_pmu_check_event_constraints_all(NULL);
-
        if (boot_cpu_has(X86_FEATURE_ARCH_LBR))
                intel_pmu_arch_lbr_init();

+       intel_pmu_check_event_constraints_all(NULL);
+
        /*
         * Access LBR MSR may cause #GP under certain circumstances.
         * Check all LBR MSR here.


>
>
>

Re: [Patch v3 1/8] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities

[Peter Zijlstra]

On Mon, Jun 15, 2026 at 08:59:29AM +0800, Mi, Dapeng wrote:
> 
> On 6/12/2026 5:46 PM, Peter Zijlstra wrote:
> > On Fri, Jun 12, 2026 at 05:01:07PM +0800, Dapeng Mi wrote:
> >> 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.
> > Again, no markdown please. I've stripped it from these patches.
> 
> My bad. Thanks a lot.
> 
> BTW, Peter, have you pull these patches? I didn't see them in perf/core or
> perf/urgent branches. Sashiko reports a defect about "Patch 5/8:
> perf/x86/intel: Validate the return value of intel_pmu_init_hybrid()". If
> not, I would post a v4 patchset to fix the defect. Thanks.
> 

I had them in queue:perf/core, but realized it was *really* late in the
window. I'll probably move them into tip post -rc1. If there's a new
version by then, I'll be sure to pick it up.

Re: [Patch v3 1/8] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities

[Mi, Dapeng]

On 6/16/2026 6:02 PM, Peter Zijlstra wrote:
> On Mon, Jun 15, 2026 at 08:59:29AM +0800, Mi, Dapeng wrote:
>> On 6/12/2026 5:46 PM, Peter Zijlstra wrote:
>>> On Fri, Jun 12, 2026 at 05:01:07PM +0800, Dapeng Mi wrote:
>>>> 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.
>>> Again, no markdown please. I've stripped it from these patches.
>> My bad. Thanks a lot.
>>
>> BTW, Peter, have you pull these patches? I didn't see them in perf/core or
>> perf/urgent branches. Sashiko reports a defect about "Patch 5/8:
>> perf/x86/intel: Validate the return value of intel_pmu_init_hybrid()". If
>> not, I would post a v4 patchset to fix the defect. Thanks.
>>
> I had them in queue:perf/core, but realized it was *really* late in the
> window. I'll probably move them into tip post -rc1. If there's a new
> version by then, I'll be sure to pick it up.

Thanks Peter. I posted the v4 patchset yesterday to fix the defect of
Sashiko. Please pick up the v4 version. Here is the v4 patchset link. 

https://lore.kernel.org/all/20260616044654.3468742-1-dapeng1.mi@linux.intel.com/

Re: [Patch v3 1/8] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities

[Mi, Dapeng]

On 6/17/2026 8:14 AM, Mi, Dapeng wrote:
> On 6/16/2026 6:02 PM, Peter Zijlstra wrote:
>> On Mon, Jun 15, 2026 at 08:59:29AM +0800, Mi, Dapeng wrote:
>>> On 6/12/2026 5:46 PM, Peter Zijlstra wrote:
>>>> On Fri, Jun 12, 2026 at 05:01:07PM +0800, Dapeng Mi wrote:
>>>>> 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.
>>>> Again, no markdown please. I've stripped it from these patches.
>>> My bad. Thanks a lot.
>>>
>>> BTW, Peter, have you pull these patches? I didn't see them in perf/core or
>>> perf/urgent branches. Sashiko reports a defect about "Patch 5/8:
>>> perf/x86/intel: Validate the return value of intel_pmu_init_hybrid()". If
>>> not, I would post a v4 patchset to fix the defect. Thanks.
>>>
>> I had them in queue:perf/core, but realized it was *really* late in the
>> window. I'll probably move them into tip post -rc1. If there's a new
>> version by then, I'll be sure to pick it up.
> Thanks Peter. I posted the v4 patchset yesterday to fix the defect of
> Sashiko. Please pick up the v4 version. Here is the v4 patchset link. 
>
> https://lore.kernel.org/all/20260616044654.3468742-1-dapeng1.mi@linux.intel.com/

Hi Peter,

Could you please queue above latest v4 patchset
(https://lore.kernel.org/all/20260616044654.3468742-1-dapeng1.mi@linux.intel.com/)
which fixes a defect in patch 5/8  "perf/x86/intel: Validate the return
value of intel_pmu_init_hybrid()"? 

Besides this change, all changes of v4 are same with this v3 patchset? 

Thanks!


>
>
>

Re: [Patch v3 1/8] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities

[Peter Zijlstra]

On Tue, Jun 30, 2026 at 05:14:41PM +0800, Mi, Dapeng wrote:
> Hi Peter,
> 
> Could you please queue above latest v4 patchset
> (https://lore.kernel.org/all/20260616044654.3468742-1-dapeng1.mi@linux.intel.com/)
> which fixes a defect in patch 5/8  "perf/x86/intel: Validate the return
> value of intel_pmu_init_hybrid()"? 
> 

Damn, I knew I was forgetting something :-(

Let me go fix that.

Re: [Patch v3 1/8] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities

[Mi, Dapeng]

On 6/30/2026 5:43 PM, Peter Zijlstra wrote:
> On Tue, Jun 30, 2026 at 05:14:41PM +0800, Mi, Dapeng wrote:
>> Hi Peter,
>>
>> Could you please queue above latest v4 patchset
>> (https://lore.kernel.org/all/20260616044654.3468742-1-dapeng1.mi@linux.intel.com/)
>> which fixes a defect in patch 5/8  "perf/x86/intel: Validate the return
>> value of intel_pmu_init_hybrid()"? 
>>
> Damn, I knew I was forgetting something :-(
>
> Let me go fix that.

Thanks! :)

[tip: perf/core] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities

[tip-bot2 for Dapeng Mi]

The following commit has been merged into the perf/core branch of tip:

Commit-ID:     9acfcb9b30b6c32ec0d8baad8b7c154120d4cff2
Gitweb:        https://git.kernel.org/tip/9acfcb9b30b6c32ec0d8baad8b7c154120d4cff2
Author:        Dapeng Mi <dapeng1.mi@linux.intel.com>
AuthorDate:    Fri, 12 Jun 2026 17:01:07 +08:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Tue, 30 Jun 2026 10:57:05 +02:00

perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities

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.

Fixes: cadbaa039b99 ("perf/x86/intel: Make anythread filter support conditional")
Reported-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Zide Chen <zide.chen@intel.com>
Reviewed-by: Thomas Falcon <thomas.falcon@intel.com>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260612090114.3188886-2-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 2b35483..465c414 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -7947,12 +7947,6 @@ __init int intel_pmu_init(void)
 
 	x86_add_quirk(intel_arch_events_quirk); /* Install first, so it runs last */
 
-	if (version >= 5) {
-		x86_pmu.intel_cap.anythread_deprecated = edx.split.anythread_deprecated;
-		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 |= PERF_PMU_CAP_MEDIATED_VPMU;
 
@@ -8829,8 +8823,10 @@ __init int intel_pmu_init(void)
 				      &x86_pmu.intel_ctrl);
 
 	/* AnyThread may be deprecated on arch perfmon v5 or later */
-	if (x86_pmu.intel_cap.anythread_deprecated)
+	if (version >= 5 && edx.split.anythread_deprecated) {
 		x86_pmu.format_attrs = intel_arch_formats_attr;
+		pr_cont("AnyThread deprecated, ");
+	}
 
 	intel_pmu_check_event_constraints_all(NULL);
 
diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
index eae24bb..5902a29 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;

[Patch v3 4/8] perf/x86/intel: Fix kernel address leakages in LBR stack

[Dapeng Mi]

Before Arch LBR gained CPL filtering support, a user-only branch stack
could still contain kernel addresses. As a result, kernel branch records
may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is
requested.

For example, on Intel Tiger Lake, the following command can still report
SYSRET/ERET entries with kernel-space from addresses:

```
$./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 problem is that intel_pmu_lbr_filter() does not fully validate the
privilege level of sampled entries. It filters some mismatches based on
the branch type and the to address, but it does not reject entries whose
from address violates the requested branch privilege filter.

Fix this by extending software filtering to validate both from and to
addresses against br_sel. Any LBR entry contains kernel address does not
match the requested user filter is dropped. This prevents kernel
addresses from appearing in user-only branch stacks.

Cc: stable@vger.kernel.org
Reported-by: Ian Rogers <irogers@google.com>
Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR")
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
---
 arch/x86/events/intel/lbr.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
index e2657f791e50..16eef1537816 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 = cpuc->br_sel;
-	int i, j, type, to_plm;
+	int i, j, type, from_plm, to_plm;
 	bool compress = false;
 
 	/* if sampling all branches, then nothing to filter */
@@ -1244,8 +1244,14 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
 				type |= X86_BR_NO_TX;
 		}
 
-		/* if type does not correspond, then discard */
-		if (type == X86_BR_NONE || (br_sel & type) != type) {
+		from_plm = kernel_ip(from) ? X86_BR_KERNEL : X86_BR_USER;
+		/*
+		 * If type does not correspond, then discard.
+		 * Specifically reject entries whose from address is in
+		 * kernel space when only X86_BR_USER is requested.
+		 */
+		if (type == X86_BR_NONE || (br_sel & type) != type ||
+		    (!(br_sel & X86_BR_KERNEL) && (from_plm & X86_BR_KERNEL))) {
 			cpuc->lbr_entries[i].from = 0;
 			compress = true;
 		}
-- 
2.34.1

[tip: perf/core] perf/x86/intel: Fix kernel address leakages in LBR stack

[tip-bot2 for Dapeng Mi]

The following commit has been merged into the perf/core branch of tip:

Commit-ID:     707ada0c09e915f6feb181d3d2d7ed957312db8d
Gitweb:        https://git.kernel.org/tip/707ada0c09e915f6feb181d3d2d7ed957312db8d
Author:        Dapeng Mi <dapeng1.mi@linux.intel.com>
AuthorDate:    Fri, 12 Jun 2026 17:01:10 +08:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Tue, 30 Jun 2026 10:57:06 +02:00

perf/x86/intel: Fix kernel address leakages in LBR stack

Before Arch LBR gained CPL filtering support, a user-only branch stack
could still contain kernel addresses. As a result, kernel branch records
may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is
requested.

For example, on Intel Tiger Lake, the following command can still report
SYSRET/ERET entries with kernel-space from addresses:

$./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 problem is that intel_pmu_lbr_filter() does not fully validate the
privilege level of sampled entries. It filters some mismatches based on
the branch type and the to address, but it does not reject entries whose
from address violates the requested branch privilege filter.

Fix this by extending software filtering to validate both from and to
addresses against br_sel. Any LBR entry contains kernel address does not
match the requested user filter is dropped. This prevents kernel
addresses from appearing in user-only branch stacks.

Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR")
Reported-by: Ian Rogers <irogers@google.com>
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260612090114.3188886-5-dapeng1.mi@linux.intel.com
---
 arch/x86/events/intel/lbr.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
index 688d1df..f8fadb0 100644
--- a/arch/x86/events/intel/lbr.c
+++ b/arch/x86/events/intel/lbr.c
@@ -1213,7 +1213,7 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
 {
 	u64 from, to;
 	int br_sel = cpuc->br_sel;
-	int i, j, type, to_plm;
+	int i, j, type, from_plm, to_plm;
 	bool compress = false;
 
 	/* if sampling all branches, then nothing to filter */
@@ -1245,8 +1245,14 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
 				type |= X86_BR_NO_TX;
 		}
 
-		/* if type does not correspond, then discard */
-		if (type == X86_BR_NONE || (br_sel & type) != type) {
+		from_plm = kernel_ip(from) ? X86_BR_KERNEL : X86_BR_USER;
+		/*
+		 * If type does not correspond, then discard.
+		 * Specifically reject entries whose from address is in
+		 * kernel space when only X86_BR_USER is requested.
+		 */
+		if (type == X86_BR_NONE || (br_sel & type) != type ||
+		    (!(br_sel & X86_BR_KERNEL) && (from_plm & X86_BR_KERNEL))) {
 			cpuc->lbr_entries[i].from = 0;
 			compress = true;
 		}