[RESEND Patch 1/2] perf/x86/intel: Only check GP counters for PEBS constraints validation

[RESEND Patch 1/2] perf/x86/intel: Only check GP counters for PEBS constraints validation

[Dapeng Mi]

It's good enough to only check GP counters for PEBS constraints
validation since constraints overlap can only happen on GP counters.

Besides opportunistically refine the code style and use pr_warn() to
replace pr_info() as the message itself is a warning message.

Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
---
 arch/x86/events/intel/core.c | 22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index cf3a4fe06ff2..4768236c054b 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -5770,7 +5770,7 @@ static void __intel_pmu_check_dyn_constr(struct event_constraint *constr,
 			}
 
 			if (check_fail) {
-				pr_info("The two events 0x%llx and 0x%llx may not be "
+				pr_warn("The two events 0x%llx and 0x%llx may not be "
 					"fully scheduled under some circumstances as "
 					"%s.\n",
 					c1->code, c2->code, dyn_constr_type_name[type]);
@@ -5783,6 +5783,7 @@ static void intel_pmu_check_dyn_constr(struct pmu *pmu,
 				       struct event_constraint *constr,
 				       u64 cntr_mask)
 {
+	u64 gp_mask = GENMASK_ULL(INTEL_PMC_MAX_GENERIC - 1, 0);
 	enum dyn_constr_type i;
 	u64 mask;
 
@@ -5797,20 +5798,25 @@ static void intel_pmu_check_dyn_constr(struct pmu *pmu,
 				mask = x86_pmu.lbr_counters;
 			break;
 		case DYN_CONSTR_ACR_CNTR:
-			mask = hybrid(pmu, acr_cntr_mask64) & GENMASK_ULL(INTEL_PMC_MAX_GENERIC - 1, 0);
+			mask = hybrid(pmu, acr_cntr_mask64) & gp_mask;
 			break;
 		case DYN_CONSTR_ACR_CAUSE:
-			if (hybrid(pmu, acr_cntr_mask64) == hybrid(pmu, acr_cause_mask64))
+			if (hybrid(pmu, acr_cntr_mask64) ==
+					hybrid(pmu, acr_cause_mask64))
 				continue;
-			mask = hybrid(pmu, acr_cause_mask64) & GENMASK_ULL(INTEL_PMC_MAX_GENERIC - 1, 0);
+			mask = hybrid(pmu, acr_cause_mask64) & gp_mask;
 			break;
 		case DYN_CONSTR_PEBS:
-			if (x86_pmu.arch_pebs)
-				mask = hybrid(pmu, arch_pebs_cap).counters;
+			if (x86_pmu.arch_pebs) {
+				mask = hybrid(pmu, arch_pebs_cap).counters &
+				       gp_mask;
+			}
 			break;
 		case DYN_CONSTR_PDIST:
-			if (x86_pmu.arch_pebs)
-				mask = hybrid(pmu, arch_pebs_cap).pdists;
+			if (x86_pmu.arch_pebs) {
+				mask = hybrid(pmu, arch_pebs_cap).pdists &
+				       gp_mask;
+			}
 			break;
 		default:
 			pr_warn("Unsupported dynamic constraint type %d\n", i);

base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
-- 
2.34.1

[RESEND Patch 2/2] perf/x86/intel: Add missing branch counters constraint apply

[Dapeng Mi]

When running the command:
'perf record -e "{instructions,instructions:p}" -j any,counter sleep 1',
a "shift-out-of-bounds" warning is reported on CWF.

[ 5231.981423][   C17] UBSAN: shift-out-of-bounds in /kbuild/src/consumer/arch/x86/events/intel/lbr.c:970:15
[ 5231.981428][   C17] shift exponent 64 is too large for 64-bit type 'long long unsigned int'
[ 5231.981436][   C17] CPU: 17 UID: 0 PID: 211871 Comm: sleep Tainted: G S      W           6.18.0-2025-12-09-intel-next-48166-g6cf574943ba3 #1 PREEMPT(none)
[ 5231.981445][   C17] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
[ 5231.981447][   C17] Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.IPC.3544.P98.2508260307 08/26/2025
[ 5231.981449][   C17] Call Trace:
[ 5231.981453][   C17]  <NMI>
[ 5231.981455][   C17]  dump_stack_lvl+0x4b/0x70
[ 5231.981463][   C17]  ubsan_epilogue+0x5/0x2b
[ 5231.981468][   C17]  __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6
[ 5231.981472][   C17]  ? __entry_text_end+0x158b/0x102259
[ 5231.981475][   C17]  intel_pmu_lbr_counters_reorder.isra.0.cold+0x2a/0xa7
[ 5231.981480][   C17]  ? __task_pid_nr_ns+0x134/0x2a0
[ 5231.981483][   C17]  ? __pfx_intel_pmu_lbr_counters_reorder.isra.0+0x10/0x10
[ 5231.981486][   C17]  ? __pfx_perf_output_sample+0x10/0x10
[ 5231.981489][   C17]  ? arch_perf_update_userpage+0x293/0x310
[ 5231.981491][   C17]  ? __pfx_arch_perf_update_userpage+0x10/0x10
[ 5231.981494][   C17]  ? local_clock_noinstr+0xd/0x100
[ 5231.981498][   C17]  ? calc_timer_values+0x2cb/0x860
[ 5231.981501][   C17]  ? perf_event_update_userpage+0x399/0x5b0
[ 5231.981505][   C17]  ? __pfx_perf_event_update_userpage+0x10/0x10
[ 5231.981508][   C17]  ? local_clock_noinstr+0xd/0x100
[ 5231.981511][   C17]  ? __perf_event_account_interrupt+0x11c/0x540
[ 5231.981514][   C17]  intel_pmu_lbr_save_brstack+0xc0/0x4c0
[ 5231.981518][   C17]  setup_arch_pebs_sample_data+0x114b/0x2400
[ 5231.981522][   C17]  ? __pfx_x86_perf_event_set_period+0x10/0x10
[ 5231.981526][   C17]  intel_pmu_drain_arch_pebs+0x64d/0xcc0
[ 5231.981530][   C17]  ? __pfx_intel_pmu_drain_arch_pebs+0x10/0x10
[ 5231.981534][   C17]  ? unwind_next_frame+0x11c5/0x1df0
[ 5231.981541][   C17]  ? intel_pmu_drain_bts_buffer+0xbf/0x6e0
[ 5231.981545][   C17]  ? __pfx_intel_pmu_drain_bts_buffer+0x10/0x10
[ 5231.981550][   C17]  handle_pmi_common+0x5c5/0xcb0
[ 5231.981553][   C17]  ? __pfx_handle_pmi_common+0x10/0x10
[ 5231.981556][   C17]  ? intel_idle+0x64/0xb0
[ 5231.981560][   C17]  ? intel_bts_interrupt+0xe5/0x4c0
[ 5231.981562][   C17]  ? __pfx_intel_bts_interrupt+0x10/0x10
[ 5231.981565][   C17]  ? intel_pmu_lbr_filter+0x27f/0x910
[ 5231.981568][   C17]  intel_pmu_handle_irq+0x2ed/0x600
[ 5231.981571][   C17]  perf_event_nmi_handler+0x219/0x280
[ 5231.981575][   C17]  ? __pfx_perf_event_nmi_handler+0x10/0x10
[ 5231.981579][   C17]  ? unwind_next_frame+0x11c5/0x1df0
[ 5231.981582][   C17]  nmi_handle.part.0+0x11b/0x3a0
[ 5231.981585][   C17]  ? unwind_next_frame+0x11c5/0x1df0
[ 5231.981588][   C17]  default_do_nmi+0x6b/0x180
[ 5231.981591][   C17]  fred_exc_nmi+0x3e/0x80
[ 5231.981594][   C17]  asm_fred_entrypoint_kernel+0x41/0x60
[ 5231.981596][   C17] RIP: 0010:unwind_next_frame+0x11c5/0x1df0
......

The warning occurs because the second "instructions:p" event, which
involves branch counters sampling, is incorrectly programmed to fixed
counter 0 instead of the general-purpose (GP) counters 0-3 that support
branch counters sampling. Currently only GP counters 0~3 support branch
counters sampling on CWF, any event involving branch counters sampling
should be programed on GP counters 0~3. Since the counter index of fixed
counter 0 is 32, it leads to the "src" value in below code is right
shifted 64 bits and trigger the "shift-out-of-bounds" warning.

cnt = (src >> (order[j] * LBR_INFO_BR_CNTR_BITS)) & LBR_INFO_BR_CNTR_MASK;

The root cause is the loss of the branch counters constraint for the
last event in the branch counters sampling event group. This results in
the second "instructions:p" event being programmed on fixed counter 0
incorrectly instead of the appropriate GP counters 0~3.

To address this, we apply the missing branch counters constraint for
the last event in the group. Additionally, we introduce a new function,
`intel_set_branch_counter_constr()`, to apply the branch counters
constraint and avoid code duplication.

Cc: stable@vger.kernel.org
Reported-by: Xudong Hao <xudong.hao@intel.com>
Fixes: 33744916196b ("perf/x86/intel: Support branch counters logging")
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
---
 arch/x86/events/intel/core.c | 30 ++++++++++++++++++++----------
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 4768236c054b..4b042d71104f 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -4628,6 +4628,19 @@ static inline void intel_pmu_set_acr_caused_constr(struct perf_event *event,
 		event->hw.dyn_constraint &= hybrid(event->pmu, acr_cause_mask64);
 }
 
+static inline int intel_set_branch_counter_constr(struct perf_event *event,
+						  int *num)
+{
+	if (branch_sample_call_stack(event))
+		return -EINVAL;
+	if (branch_sample_counters(event)) {
+		(*num)++;
+		event->hw.dyn_constraint &= x86_pmu.lbr_counters;
+	}
+
+	return 0;
+}
+
 static int intel_pmu_hw_config(struct perf_event *event)
 {
 	int ret = x86_pmu_hw_config(event);
@@ -4698,21 +4711,18 @@ static int intel_pmu_hw_config(struct perf_event *event)
 		 * group, which requires the extra space to store the counters.
 		 */
 		leader = event->group_leader;
-		if (branch_sample_call_stack(leader))
+		if (intel_set_branch_counter_constr(leader, &num))
 			return -EINVAL;
-		if (branch_sample_counters(leader)) {
-			num++;
-			leader->hw.dyn_constraint &= x86_pmu.lbr_counters;
-		}
 		leader->hw.flags |= PERF_X86_EVENT_BRANCH_COUNTERS;
 
 		for_each_sibling_event(sibling, leader) {
-			if (branch_sample_call_stack(sibling))
+			if (intel_set_branch_counter_constr(sibling, &num))
+				return -EINVAL;
+		}
+
+		if (event != leader) {
+			if (intel_set_branch_counter_constr(event, &num))
 				return -EINVAL;
-			if (branch_sample_counters(sibling)) {
-				num++;
-				sibling->hw.dyn_constraint &= x86_pmu.lbr_counters;
-			}
 		}
 
 		if (num > fls(x86_pmu.lbr_counters))
-- 
2.34.1

Re: [RESEND Patch 2/2] perf/x86/intel: Add missing branch counters constraint apply

[Chen, Zide]

On 2/27/2026 9:33 PM, Dapeng Mi wrote:
> When running the command:
> 'perf record -e "{instructions,instructions:p}" -j any,counter sleep 1',
> a "shift-out-of-bounds" warning is reported on CWF.
> 
> [ 5231.981423][   C17] UBSAN: shift-out-of-bounds in /kbuild/src/consumer/arch/x86/events/intel/lbr.c:970:15
> [ 5231.981428][   C17] shift exponent 64 is too large for 64-bit type 'long long unsigned int'
> [ 5231.981436][   C17] CPU: 17 UID: 0 PID: 211871 Comm: sleep Tainted: G S      W           6.18.0-2025-12-09-intel-next-48166-g6cf574943ba3 #1 PREEMPT(none)
> [ 5231.981445][   C17] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
> [ 5231.981447][   C17] Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.IPC.3544.P98.2508260307 08/26/2025
> [ 5231.981449][   C17] Call Trace:
> [ 5231.981453][   C17]  <NMI>
> [ 5231.981455][   C17]  dump_stack_lvl+0x4b/0x70
> [ 5231.981463][   C17]  ubsan_epilogue+0x5/0x2b
> [ 5231.981468][   C17]  __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6
> [ 5231.981472][   C17]  ? __entry_text_end+0x158b/0x102259
> [ 5231.981475][   C17]  intel_pmu_lbr_counters_reorder.isra.0.cold+0x2a/0xa7
> [ 5231.981480][   C17]  ? __task_pid_nr_ns+0x134/0x2a0
> [ 5231.981483][   C17]  ? __pfx_intel_pmu_lbr_counters_reorder.isra.0+0x10/0x10
> [ 5231.981486][   C17]  ? __pfx_perf_output_sample+0x10/0x10
> [ 5231.981489][   C17]  ? arch_perf_update_userpage+0x293/0x310
> [ 5231.981491][   C17]  ? __pfx_arch_perf_update_userpage+0x10/0x10
> [ 5231.981494][   C17]  ? local_clock_noinstr+0xd/0x100
> [ 5231.981498][   C17]  ? calc_timer_values+0x2cb/0x860
> [ 5231.981501][   C17]  ? perf_event_update_userpage+0x399/0x5b0
> [ 5231.981505][   C17]  ? __pfx_perf_event_update_userpage+0x10/0x10
> [ 5231.981508][   C17]  ? local_clock_noinstr+0xd/0x100
> [ 5231.981511][   C17]  ? __perf_event_account_interrupt+0x11c/0x540
> [ 5231.981514][   C17]  intel_pmu_lbr_save_brstack+0xc0/0x4c0
> [ 5231.981518][   C17]  setup_arch_pebs_sample_data+0x114b/0x2400
> [ 5231.981522][   C17]  ? __pfx_x86_perf_event_set_period+0x10/0x10
> [ 5231.981526][   C17]  intel_pmu_drain_arch_pebs+0x64d/0xcc0
> [ 5231.981530][   C17]  ? __pfx_intel_pmu_drain_arch_pebs+0x10/0x10
> [ 5231.981534][   C17]  ? unwind_next_frame+0x11c5/0x1df0
> [ 5231.981541][   C17]  ? intel_pmu_drain_bts_buffer+0xbf/0x6e0
> [ 5231.981545][   C17]  ? __pfx_intel_pmu_drain_bts_buffer+0x10/0x10
> [ 5231.981550][   C17]  handle_pmi_common+0x5c5/0xcb0
> [ 5231.981553][   C17]  ? __pfx_handle_pmi_common+0x10/0x10
> [ 5231.981556][   C17]  ? intel_idle+0x64/0xb0
> [ 5231.981560][   C17]  ? intel_bts_interrupt+0xe5/0x4c0
> [ 5231.981562][   C17]  ? __pfx_intel_bts_interrupt+0x10/0x10
> [ 5231.981565][   C17]  ? intel_pmu_lbr_filter+0x27f/0x910
> [ 5231.981568][   C17]  intel_pmu_handle_irq+0x2ed/0x600
> [ 5231.981571][   C17]  perf_event_nmi_handler+0x219/0x280
> [ 5231.981575][   C17]  ? __pfx_perf_event_nmi_handler+0x10/0x10
> [ 5231.981579][   C17]  ? unwind_next_frame+0x11c5/0x1df0
> [ 5231.981582][   C17]  nmi_handle.part.0+0x11b/0x3a0
> [ 5231.981585][   C17]  ? unwind_next_frame+0x11c5/0x1df0
> [ 5231.981588][   C17]  default_do_nmi+0x6b/0x180
> [ 5231.981591][   C17]  fred_exc_nmi+0x3e/0x80
> [ 5231.981594][   C17]  asm_fred_entrypoint_kernel+0x41/0x60
> [ 5231.981596][   C17] RIP: 0010:unwind_next_frame+0x11c5/0x1df0
> ......
> 
> The warning occurs because the second "instructions:p" event, which
> involves branch counters sampling, is incorrectly programmed to fixed
> counter 0 instead of the general-purpose (GP) counters 0-3 that support
> branch counters sampling. Currently only GP counters 0~3 support branch
> counters sampling on CWF, any event involving branch counters sampling
> should be programed on GP counters 0~3.
> Since the counter index of fixed> counter 0 is 32, it leads to the "src" value in below code is right
> shifted 64 bits and trigger the "shift-out-of-bounds" warning.
> 
> cnt = (src >> (order[j] * LBR_INFO_BR_CNTR_BITS)) & LBR_INFO_BR_CNTR_MASK;
> 
> The root cause is the loss of the branch counters constraint for the
> last event in the branch counters sampling event group. This results in
> the second "instructions:p" event being programmed on fixed counter 0
> incorrectly instead of the appropriate GP counters 0~3.
> 
> To address this, we apply the missing branch counters constraint for
> the last event in the group. Additionally, we introduce a new function,
> `intel_set_branch_counter_constr()`, to apply the branch counters
> constraint and avoid code duplication.
> 
> Cc: stable@vger.kernel.org
> Reported-by: Xudong Hao <xudong.hao@intel.com>
> Fixes: 33744916196b ("perf/x86/intel: Support branch counters logging")
> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> ---

Reviewed-by: Zide Chen <zide.chen@intel.com>

>  arch/x86/events/intel/core.c | 30 ++++++++++++++++++++----------
>  1 file changed, 20 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index 4768236c054b..4b042d71104f 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -4628,6 +4628,19 @@ static inline void intel_pmu_set_acr_caused_constr(struct perf_event *event,
>  		event->hw.dyn_constraint &= hybrid(event->pmu, acr_cause_mask64);
>  }
>  
> +static inline int intel_set_branch_counter_constr(struct perf_event *event,
> +						  int *num)
> +{
> +	if (branch_sample_call_stack(event))
> +		return -EINVAL;
> +	if (branch_sample_counters(event)) {
> +		(*num)++;
> +		event->hw.dyn_constraint &= x86_pmu.lbr_counters;
> +	}
> +
> +	return 0;
> +}
> +
>  static int intel_pmu_hw_config(struct perf_event *event)
>  {
>  	int ret = x86_pmu_hw_config(event);
> @@ -4698,21 +4711,18 @@ static int intel_pmu_hw_config(struct perf_event *event)
>  		 * group, which requires the extra space to store the counters.
>  		 */
>  		leader = event->group_leader;
> -		if (branch_sample_call_stack(leader))
> +		if (intel_set_branch_counter_constr(leader, &num))
>  			return -EINVAL;
> -		if (branch_sample_counters(leader)) {
> -			num++;
> -			leader->hw.dyn_constraint &= x86_pmu.lbr_counters;
> -		}
>  		leader->hw.flags |= PERF_X86_EVENT_BRANCH_COUNTERS;
>  
>  		for_each_sibling_event(sibling, leader) {
> -			if (branch_sample_call_stack(sibling))
> +			if (intel_set_branch_counter_constr(sibling, &num))
> +				return -EINVAL;
> +		}
> +
> +		if (event != leader) {
> +			if (intel_set_branch_counter_constr(event, &num))
>  				return -EINVAL;
> -			if (branch_sample_counters(sibling)) {
> -				num++;
> -				sibling->hw.dyn_constraint &= x86_pmu.lbr_counters;
> -			}
>  		}
>  
>  		if (num > fls(x86_pmu.lbr_counters))

Re: [RESEND Patch 2/2] perf/x86/intel: Add missing branch counters constraint apply

[Peter Zijlstra]

On Fri, Mar 06, 2026 at 05:27:35PM -0800, Chen, Zide wrote:
> 
> 
> On 2/27/2026 9:33 PM, Dapeng Mi wrote:
> > When running the command:
> > 'perf record -e "{instructions,instructions:p}" -j any,counter sleep 1',
> > a "shift-out-of-bounds" warning is reported on CWF.
> > 
> > [ 5231.981423][   C17] UBSAN: shift-out-of-bounds in /kbuild/src/consumer/arch/x86/events/intel/lbr.c:970:15
> > [ 5231.981428][   C17] shift exponent 64 is too large for 64-bit type 'long long unsigned int'
> > [ 5231.981436][   C17] CPU: 17 UID: 0 PID: 211871 Comm: sleep Tainted: G S      W           6.18.0-2025-12-09-intel-next-48166-g6cf574943ba3 #1 PREEMPT(none)
> > [ 5231.981445][   C17] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
> > [ 5231.981447][   C17] Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.IPC.3544.P98.2508260307 08/26/2025
> > [ 5231.981449][   C17] Call Trace:
> > [ 5231.981453][   C17]  <NMI>
> > [ 5231.981455][   C17]  dump_stack_lvl+0x4b/0x70
> > [ 5231.981463][   C17]  ubsan_epilogue+0x5/0x2b
> > [ 5231.981468][   C17]  __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6
> > [ 5231.981472][   C17]  ? __entry_text_end+0x158b/0x102259
> > [ 5231.981475][   C17]  intel_pmu_lbr_counters_reorder.isra.0.cold+0x2a/0xa7
> > [ 5231.981480][   C17]  ? __task_pid_nr_ns+0x134/0x2a0
> > [ 5231.981483][   C17]  ? __pfx_intel_pmu_lbr_counters_reorder.isra.0+0x10/0x10
> > [ 5231.981486][   C17]  ? __pfx_perf_output_sample+0x10/0x10
> > [ 5231.981489][   C17]  ? arch_perf_update_userpage+0x293/0x310
> > [ 5231.981491][   C17]  ? __pfx_arch_perf_update_userpage+0x10/0x10
> > [ 5231.981494][   C17]  ? local_clock_noinstr+0xd/0x100
> > [ 5231.981498][   C17]  ? calc_timer_values+0x2cb/0x860
> > [ 5231.981501][   C17]  ? perf_event_update_userpage+0x399/0x5b0
> > [ 5231.981505][   C17]  ? __pfx_perf_event_update_userpage+0x10/0x10
> > [ 5231.981508][   C17]  ? local_clock_noinstr+0xd/0x100
> > [ 5231.981511][   C17]  ? __perf_event_account_interrupt+0x11c/0x540
> > [ 5231.981514][   C17]  intel_pmu_lbr_save_brstack+0xc0/0x4c0
> > [ 5231.981518][   C17]  setup_arch_pebs_sample_data+0x114b/0x2400
> > [ 5231.981522][   C17]  ? __pfx_x86_perf_event_set_period+0x10/0x10
> > [ 5231.981526][   C17]  intel_pmu_drain_arch_pebs+0x64d/0xcc0
> > [ 5231.981530][   C17]  ? __pfx_intel_pmu_drain_arch_pebs+0x10/0x10
> > [ 5231.981534][   C17]  ? unwind_next_frame+0x11c5/0x1df0
> > [ 5231.981541][   C17]  ? intel_pmu_drain_bts_buffer+0xbf/0x6e0
> > [ 5231.981545][   C17]  ? __pfx_intel_pmu_drain_bts_buffer+0x10/0x10
> > [ 5231.981550][   C17]  handle_pmi_common+0x5c5/0xcb0
> > [ 5231.981553][   C17]  ? __pfx_handle_pmi_common+0x10/0x10
> > [ 5231.981556][   C17]  ? intel_idle+0x64/0xb0
> > [ 5231.981560][   C17]  ? intel_bts_interrupt+0xe5/0x4c0
> > [ 5231.981562][   C17]  ? __pfx_intel_bts_interrupt+0x10/0x10
> > [ 5231.981565][   C17]  ? intel_pmu_lbr_filter+0x27f/0x910
> > [ 5231.981568][   C17]  intel_pmu_handle_irq+0x2ed/0x600
> > [ 5231.981571][   C17]  perf_event_nmi_handler+0x219/0x280
> > [ 5231.981575][   C17]  ? __pfx_perf_event_nmi_handler+0x10/0x10
> > [ 5231.981579][   C17]  ? unwind_next_frame+0x11c5/0x1df0
> > [ 5231.981582][   C17]  nmi_handle.part.0+0x11b/0x3a0
> > [ 5231.981585][   C17]  ? unwind_next_frame+0x11c5/0x1df0
> > [ 5231.981588][   C17]  default_do_nmi+0x6b/0x180
> > [ 5231.981591][   C17]  fred_exc_nmi+0x3e/0x80
> > [ 5231.981594][   C17]  asm_fred_entrypoint_kernel+0x41/0x60
> > [ 5231.981596][   C17] RIP: 0010:unwind_next_frame+0x11c5/0x1df0
> > ......

That trace could be reduced to:

  UBSAN: shift-out-of-bounds in /kbuild/src/consumer/arch/x86/events/intel/lbr.c:970:15
  shift exponent 64 is too large for 64-bit type 'long long unsigned int'
  ......
  intel_pmu_lbr_counters_reorder.isra.0.cold+0x2a/0xa7
  intel_pmu_lbr_save_brstack+0xc0/0x4c0
  setup_arch_pebs_sample_data+0x114b/0x2400

Without loosing anything valuable.


> > The warning occurs because the second "instructions:p" event, which
> > involves branch counters sampling, is incorrectly programmed to fixed
> > counter 0 instead of the general-purpose (GP) counters 0-3 that support

So here you have 0-3, the normal 'range' notation, but then you go all
funny and use ~ instead:

> > branch counters sampling. Currently only GP counters 0~3 support branch
> > counters sampling on CWF, any event involving branch counters sampling
> > should be programed on GP counters 0~3.
> > Since the counter index of fixed> counter 0 is 32, it leads to the "src" value in below code is right
> > shifted 64 bits and trigger the "shift-out-of-bounds" warning.
> > 
> > cnt = (src >> (order[j] * LBR_INFO_BR_CNTR_BITS)) & LBR_INFO_BR_CNTR_MASK;
> > 
> > The root cause is the loss of the branch counters constraint for the
> > last event in the branch counters sampling event group. This results in
> > the second "instructions:p" event being programmed on fixed counter 0
> > incorrectly instead of the appropriate GP counters 0~3.

s/0~3/0-3/ ?

Re: [RESEND Patch 2/2] perf/x86/intel: Add missing branch counters constraint apply

[Mi, Dapeng]

On 3/12/2026 4:03 AM, Peter Zijlstra wrote:
> On Fri, Mar 06, 2026 at 05:27:35PM -0800, Chen, Zide wrote:
>>
>> On 2/27/2026 9:33 PM, Dapeng Mi wrote:
>>> When running the command:
>>> 'perf record -e "{instructions,instructions:p}" -j any,counter sleep 1',
>>> a "shift-out-of-bounds" warning is reported on CWF.
>>>
>>> [ 5231.981423][   C17] UBSAN: shift-out-of-bounds in /kbuild/src/consumer/arch/x86/events/intel/lbr.c:970:15
>>> [ 5231.981428][   C17] shift exponent 64 is too large for 64-bit type 'long long unsigned int'
>>> [ 5231.981436][   C17] CPU: 17 UID: 0 PID: 211871 Comm: sleep Tainted: G S      W           6.18.0-2025-12-09-intel-next-48166-g6cf574943ba3 #1 PREEMPT(none)
>>> [ 5231.981445][   C17] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
>>> [ 5231.981447][   C17] Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.IPC.3544.P98.2508260307 08/26/2025
>>> [ 5231.981449][   C17] Call Trace:
>>> [ 5231.981453][   C17]  <NMI>
>>> [ 5231.981455][   C17]  dump_stack_lvl+0x4b/0x70
>>> [ 5231.981463][   C17]  ubsan_epilogue+0x5/0x2b
>>> [ 5231.981468][   C17]  __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6
>>> [ 5231.981472][   C17]  ? __entry_text_end+0x158b/0x102259
>>> [ 5231.981475][   C17]  intel_pmu_lbr_counters_reorder.isra.0.cold+0x2a/0xa7
>>> [ 5231.981480][   C17]  ? __task_pid_nr_ns+0x134/0x2a0
>>> [ 5231.981483][   C17]  ? __pfx_intel_pmu_lbr_counters_reorder.isra.0+0x10/0x10
>>> [ 5231.981486][   C17]  ? __pfx_perf_output_sample+0x10/0x10
>>> [ 5231.981489][   C17]  ? arch_perf_update_userpage+0x293/0x310
>>> [ 5231.981491][   C17]  ? __pfx_arch_perf_update_userpage+0x10/0x10
>>> [ 5231.981494][   C17]  ? local_clock_noinstr+0xd/0x100
>>> [ 5231.981498][   C17]  ? calc_timer_values+0x2cb/0x860
>>> [ 5231.981501][   C17]  ? perf_event_update_userpage+0x399/0x5b0
>>> [ 5231.981505][   C17]  ? __pfx_perf_event_update_userpage+0x10/0x10
>>> [ 5231.981508][   C17]  ? local_clock_noinstr+0xd/0x100
>>> [ 5231.981511][   C17]  ? __perf_event_account_interrupt+0x11c/0x540
>>> [ 5231.981514][   C17]  intel_pmu_lbr_save_brstack+0xc0/0x4c0
>>> [ 5231.981518][   C17]  setup_arch_pebs_sample_data+0x114b/0x2400
>>> [ 5231.981522][   C17]  ? __pfx_x86_perf_event_set_period+0x10/0x10
>>> [ 5231.981526][   C17]  intel_pmu_drain_arch_pebs+0x64d/0xcc0
>>> [ 5231.981530][   C17]  ? __pfx_intel_pmu_drain_arch_pebs+0x10/0x10
>>> [ 5231.981534][   C17]  ? unwind_next_frame+0x11c5/0x1df0
>>> [ 5231.981541][   C17]  ? intel_pmu_drain_bts_buffer+0xbf/0x6e0
>>> [ 5231.981545][   C17]  ? __pfx_intel_pmu_drain_bts_buffer+0x10/0x10
>>> [ 5231.981550][   C17]  handle_pmi_common+0x5c5/0xcb0
>>> [ 5231.981553][   C17]  ? __pfx_handle_pmi_common+0x10/0x10
>>> [ 5231.981556][   C17]  ? intel_idle+0x64/0xb0
>>> [ 5231.981560][   C17]  ? intel_bts_interrupt+0xe5/0x4c0
>>> [ 5231.981562][   C17]  ? __pfx_intel_bts_interrupt+0x10/0x10
>>> [ 5231.981565][   C17]  ? intel_pmu_lbr_filter+0x27f/0x910
>>> [ 5231.981568][   C17]  intel_pmu_handle_irq+0x2ed/0x600
>>> [ 5231.981571][   C17]  perf_event_nmi_handler+0x219/0x280
>>> [ 5231.981575][   C17]  ? __pfx_perf_event_nmi_handler+0x10/0x10
>>> [ 5231.981579][   C17]  ? unwind_next_frame+0x11c5/0x1df0
>>> [ 5231.981582][   C17]  nmi_handle.part.0+0x11b/0x3a0
>>> [ 5231.981585][   C17]  ? unwind_next_frame+0x11c5/0x1df0
>>> [ 5231.981588][   C17]  default_do_nmi+0x6b/0x180
>>> [ 5231.981591][   C17]  fred_exc_nmi+0x3e/0x80
>>> [ 5231.981594][   C17]  asm_fred_entrypoint_kernel+0x41/0x60
>>> [ 5231.981596][   C17] RIP: 0010:unwind_next_frame+0x11c5/0x1df0
>>> ......
> That trace could be reduced to:
>
>   UBSAN: shift-out-of-bounds in /kbuild/src/consumer/arch/x86/events/intel/lbr.c:970:15
>   shift exponent 64 is too large for 64-bit type 'long long unsigned int'
>   ......
>   intel_pmu_lbr_counters_reorder.isra.0.cold+0x2a/0xa7
>   intel_pmu_lbr_save_brstack+0xc0/0x4c0
>   setup_arch_pebs_sample_data+0x114b/0x2400
>
> Without loosing anything valuable.

Sure.


>
>
>>> The warning occurs because the second "instructions:p" event, which
>>> involves branch counters sampling, is incorrectly programmed to fixed
>>> counter 0 instead of the general-purpose (GP) counters 0-3 that support
> So here you have 0-3, the normal 'range' notation, but then you go all
> funny and use ~ instead:

😂


>
>>> branch counters sampling. Currently only GP counters 0~3 support branch
>>> counters sampling on CWF, any event involving branch counters sampling
>>> should be programed on GP counters 0~3.
>>> Since the counter index of fixed> counter 0 is 32, it leads to the "src" value in below code is right
>>> shifted 64 bits and trigger the "shift-out-of-bounds" warning.
>>>
>>> cnt = (src >> (order[j] * LBR_INFO_BR_CNTR_BITS)) & LBR_INFO_BR_CNTR_MASK;
>>>
>>> The root cause is the loss of the branch counters constraint for the
>>> last event in the branch counters sampling event group. This results in
>>> the second "instructions:p" event being programmed on fixed counter 0
>>> incorrectly instead of the appropriate GP counters 0~3.
> s/0~3/0-3/ ?

Sure.


>

Re: [RESEND Patch 2/2] perf/x86/intel: Add missing branch counters constraint apply

[Peter Zijlstra]

On Sat, Feb 28, 2026 at 01:33:20PM +0800, Dapeng Mi wrote:
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index 4768236c054b..4b042d71104f 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -4628,6 +4628,19 @@ static inline void intel_pmu_set_acr_caused_constr(struct perf_event *event,
>  		event->hw.dyn_constraint &= hybrid(event->pmu, acr_cause_mask64);
>  }
>  
> +static inline int intel_set_branch_counter_constr(struct perf_event *event,
> +						  int *num)
> +{
> +	if (branch_sample_call_stack(event))
> +		return -EINVAL;
> +	if (branch_sample_counters(event)) {
> +		(*num)++;
> +		event->hw.dyn_constraint &= x86_pmu.lbr_counters;
> +	}
> +
> +	return 0;
> +}
> +
>  static int intel_pmu_hw_config(struct perf_event *event)
>  {
>  	int ret = x86_pmu_hw_config(event);
> @@ -4698,21 +4711,18 @@ static int intel_pmu_hw_config(struct perf_event *event)
>  		 * group, which requires the extra space to store the counters.
>  		 */
>  		leader = event->group_leader;
> +		if (intel_set_branch_counter_constr(leader, &num))
>  			return -EINVAL;
>  		leader->hw.flags |= PERF_X86_EVENT_BRANCH_COUNTERS;
>  
>  		for_each_sibling_event(sibling, leader) {
> +			if (intel_set_branch_counter_constr(sibling, &num))
> +				return -EINVAL;
> +		}
> +

Do the new bit is this, right?

> +		if (event != leader) {
> +			if (intel_set_branch_counter_constr(event, &num))
>  				return -EINVAL;
>  		}

The point being that for_each_sibling_event() will not have iterated the
event because its not on the list yet?

That wasn't really clear from the changelog and I think that deserves a
comment as well.

Let me go fix that.

Re: [RESEND Patch 2/2] perf/x86/intel: Add missing branch counters constraint apply

[Mi, Dapeng]

On 3/12/2026 4:16 AM, Peter Zijlstra wrote:
> On Sat, Feb 28, 2026 at 01:33:20PM +0800, Dapeng Mi wrote:
>> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
>> index 4768236c054b..4b042d71104f 100644
>> --- a/arch/x86/events/intel/core.c
>> +++ b/arch/x86/events/intel/core.c
>> @@ -4628,6 +4628,19 @@ static inline void intel_pmu_set_acr_caused_constr(struct perf_event *event,
>>  		event->hw.dyn_constraint &= hybrid(event->pmu, acr_cause_mask64);
>>  }
>>  
>> +static inline int intel_set_branch_counter_constr(struct perf_event *event,
>> +						  int *num)
>> +{
>> +	if (branch_sample_call_stack(event))
>> +		return -EINVAL;
>> +	if (branch_sample_counters(event)) {
>> +		(*num)++;
>> +		event->hw.dyn_constraint &= x86_pmu.lbr_counters;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>>  static int intel_pmu_hw_config(struct perf_event *event)
>>  {
>>  	int ret = x86_pmu_hw_config(event);
>> @@ -4698,21 +4711,18 @@ static int intel_pmu_hw_config(struct perf_event *event)
>>  		 * group, which requires the extra space to store the counters.
>>  		 */
>>  		leader = event->group_leader;
>> +		if (intel_set_branch_counter_constr(leader, &num))
>>  			return -EINVAL;
>>  		leader->hw.flags |= PERF_X86_EVENT_BRANCH_COUNTERS;
>>  
>>  		for_each_sibling_event(sibling, leader) {
>> +			if (intel_set_branch_counter_constr(sibling, &num))
>> +				return -EINVAL;
>> +		}
>> +
> Do the new bit is this, right?

Actually not, the key change is the below one. The last event in the group
is not applied the branch counter constraint.

Assume we have a event group {cycles,instructions,branches}. When the 3rd
event "branches" is created and the function intel_pmu_hw_config() is
called for the "branches" event to check the config.  The event leader is
"cycles" and the sibling event has only the "instructions" event at that
time since the 3rd event "branches" is in creation and still not added into
the sibling_list. So for_each_sibling_event() can't really iterate the
"branches" event.


>
>> +		if (event != leader) {
>> +			if (intel_set_branch_counter_constr(event, &num))
>>  				return -EINVAL;
>>  		}
> The point being that for_each_sibling_event() will not have iterated the
> event because its not on the list yet?

Yes. 


>
> That wasn't really clear from the changelog and I think that deserves a
> comment as well.

Sure. I would add comment and enhance the changelog to make it clearer. Thanks.


>
> Let me go fix that.

Re: [RESEND Patch 2/2] perf/x86/intel: Add missing branch counters constraint apply

[Peter Zijlstra]

On Thu, Mar 12, 2026 at 10:31:28AM +0800, Mi, Dapeng wrote:
> 
> On 3/12/2026 4:16 AM, Peter Zijlstra wrote:
> > On Sat, Feb 28, 2026 at 01:33:20PM +0800, Dapeng Mi wrote:
> >> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> >> index 4768236c054b..4b042d71104f 100644
> >> --- a/arch/x86/events/intel/core.c
> >> +++ b/arch/x86/events/intel/core.c
> >> @@ -4628,6 +4628,19 @@ static inline void intel_pmu_set_acr_caused_constr(struct perf_event *event,
> >>  		event->hw.dyn_constraint &= hybrid(event->pmu, acr_cause_mask64);
> >>  }
> >>  
> >> +static inline int intel_set_branch_counter_constr(struct perf_event *event,
> >> +						  int *num)
> >> +{
> >> +	if (branch_sample_call_stack(event))
> >> +		return -EINVAL;
> >> +	if (branch_sample_counters(event)) {
> >> +		(*num)++;
> >> +		event->hw.dyn_constraint &= x86_pmu.lbr_counters;
> >> +	}
> >> +
> >> +	return 0;
> >> +}
> >> +
> >>  static int intel_pmu_hw_config(struct perf_event *event)
> >>  {
> >>  	int ret = x86_pmu_hw_config(event);
> >> @@ -4698,21 +4711,18 @@ static int intel_pmu_hw_config(struct perf_event *event)
> >>  		 * group, which requires the extra space to store the counters.
> >>  		 */
> >>  		leader = event->group_leader;
> >> +		if (intel_set_branch_counter_constr(leader, &num))
> >>  			return -EINVAL;
> >>  		leader->hw.flags |= PERF_X86_EVENT_BRANCH_COUNTERS;
> >>  
> >>  		for_each_sibling_event(sibling, leader) {
> >> +			if (intel_set_branch_counter_constr(sibling, &num))
> >> +				return -EINVAL;
> >> +		}
> >> +
> > Do the new bit is this, right?
> 
> Actually not, the key change is the below one. The last event in the group
> is not applied the branch counter constraint.
> 
> Assume we have a event group {cycles,instructions,branches}. When the 3rd
> event "branches" is created and the function intel_pmu_hw_config() is
> called for the "branches" event to check the config.  The event leader is
> "cycles" and the sibling event has only the "instructions" event at that
> time since the 3rd event "branches" is in creation and still not added into
> the sibling_list. So for_each_sibling_event() can't really iterate the
> "branches" event.
> 
> 
> >
> >> +		if (event != leader) {
> >> +			if (intel_set_branch_counter_constr(event, &num))
> >>  				return -EINVAL;
> >>  		}
> > The point being that for_each_sibling_event() will not have iterated the
> > event because its not on the list yet?
> 
> Yes. 
> 
> 
> >
> > That wasn't really clear from the changelog and I think that deserves a
> > comment as well.
> 
> Sure. I would add comment and enhance the changelog to make it clearer. Thanks.
> 

I already fixed everything up. Should be in queue/perf/urgent.

Re: [RESEND Patch 2/2] perf/x86/intel: Add missing branch counters constraint apply

[Mi, Dapeng]

On 3/12/2026 2:41 PM, Peter Zijlstra wrote:
> On Thu, Mar 12, 2026 at 10:31:28AM +0800, Mi, Dapeng wrote:
>> On 3/12/2026 4:16 AM, Peter Zijlstra wrote:
>>> On Sat, Feb 28, 2026 at 01:33:20PM +0800, Dapeng Mi wrote:
>>>> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
>>>> index 4768236c054b..4b042d71104f 100644
>>>> --- a/arch/x86/events/intel/core.c
>>>> +++ b/arch/x86/events/intel/core.c
>>>> @@ -4628,6 +4628,19 @@ static inline void intel_pmu_set_acr_caused_constr(struct perf_event *event,
>>>>  		event->hw.dyn_constraint &= hybrid(event->pmu, acr_cause_mask64);
>>>>  }
>>>>  
>>>> +static inline int intel_set_branch_counter_constr(struct perf_event *event,
>>>> +						  int *num)
>>>> +{
>>>> +	if (branch_sample_call_stack(event))
>>>> +		return -EINVAL;
>>>> +	if (branch_sample_counters(event)) {
>>>> +		(*num)++;
>>>> +		event->hw.dyn_constraint &= x86_pmu.lbr_counters;
>>>> +	}
>>>> +
>>>> +	return 0;
>>>> +}
>>>> +
>>>>  static int intel_pmu_hw_config(struct perf_event *event)
>>>>  {
>>>>  	int ret = x86_pmu_hw_config(event);
>>>> @@ -4698,21 +4711,18 @@ static int intel_pmu_hw_config(struct perf_event *event)
>>>>  		 * group, which requires the extra space to store the counters.
>>>>  		 */
>>>>  		leader = event->group_leader;
>>>> +		if (intel_set_branch_counter_constr(leader, &num))
>>>>  			return -EINVAL;
>>>>  		leader->hw.flags |= PERF_X86_EVENT_BRANCH_COUNTERS;
>>>>  
>>>>  		for_each_sibling_event(sibling, leader) {
>>>> +			if (intel_set_branch_counter_constr(sibling, &num))
>>>> +				return -EINVAL;
>>>> +		}
>>>> +
>>> Do the new bit is this, right?
>> Actually not, the key change is the below one. The last event in the group
>> is not applied the branch counter constraint.
>>
>> Assume we have a event group {cycles,instructions,branches}. When the 3rd
>> event "branches" is created and the function intel_pmu_hw_config() is
>> called for the "branches" event to check the config.  The event leader is
>> "cycles" and the sibling event has only the "instructions" event at that
>> time since the 3rd event "branches" is in creation and still not added into
>> the sibling_list. So for_each_sibling_event() can't really iterate the
>> "branches" event.
>>
>>
>>>> +		if (event != leader) {
>>>> +			if (intel_set_branch_counter_constr(event, &num))
>>>>  				return -EINVAL;
>>>>  		}
>>> The point being that for_each_sibling_event() will not have iterated the
>>> event because its not on the list yet?
>> Yes. 
>>
>>
>>> That wasn't really clear from the changelog and I think that deserves a
>>> comment as well.
>> Sure. I would add comment and enhance the changelog to make it clearer. Thanks.
>>
> I already fixed everything up. Should be in queue/perf/urgent.

Thanks. 

Peter, As Ian points out, the patch "perf/x86: Update cap_user_rdpmc base
on rdpmc user disable state" has a bug
(https://lore.kernel.org/all/CAP-5=fWr2L6miiFZ6Km3HYEdmqp3T0NBL=WY3buKdKztW+HvmA@mail.gmail.com/).
I would posted a patch to fix the issue. Thanks.



>

Re: [RESEND Patch 2/2] perf/x86/intel: Add missing branch counters constraint apply

[Peter Zijlstra]

On Thu, Mar 12, 2026 at 02:52:43PM +0800, Mi, Dapeng wrote:
> 
> Peter, As Ian points out, the patch "perf/x86: Update cap_user_rdpmc base
> on rdpmc user disable state" has a bug
> (https://lore.kernel.org/all/CAP-5=fWr2L6miiFZ6Km3HYEdmqp3T0NBL=WY3buKdKztW+HvmA@mail.gmail.com/).
> I would posted a patch to fix the issue. Thanks.
> 

Yep, saw that, its gone :-)

Re: [RESEND Patch 1/2] perf/x86/intel: Only check GP counters for PEBS constraints validation

[Chen, Zide]

On 2/27/2026 9:33 PM, Dapeng Mi wrote:
> It's good enough to only check GP counters for PEBS constraints
> validation since constraints overlap can only happen on GP counters.
> 
> Besides opportunistically refine the code style and use pr_warn() to
> replace pr_info() as the message itself is a warning message.
> 
> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> ---

LGTM.

Reviewed-by: Zide Chen <zide.chen@intel.com>

>  arch/x86/events/intel/core.c | 22 ++++++++++++++--------
>  1 file changed, 14 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index cf3a4fe06ff2..4768236c054b 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -5770,7 +5770,7 @@ static void __intel_pmu_check_dyn_constr(struct event_constraint *constr,
>  			}
>  
>  			if (check_fail) {
> -				pr_info("The two events 0x%llx and 0x%llx may not be "
> +				pr_warn("The two events 0x%llx and 0x%llx may not be "
>  					"fully scheduled under some circumstances as "
>  					"%s.\n",
>  					c1->code, c2->code, dyn_constr_type_name[type]);
> @@ -5783,6 +5783,7 @@ static void intel_pmu_check_dyn_constr(struct pmu *pmu,
>  				       struct event_constraint *constr,
>  				       u64 cntr_mask)
>  {
> +	u64 gp_mask = GENMASK_ULL(INTEL_PMC_MAX_GENERIC - 1, 0);
>  	enum dyn_constr_type i;
>  	u64 mask;
>  
> @@ -5797,20 +5798,25 @@ static void intel_pmu_check_dyn_constr(struct pmu *pmu,
>  				mask = x86_pmu.lbr_counters;
>  			break;
>  		case DYN_CONSTR_ACR_CNTR:
> -			mask = hybrid(pmu, acr_cntr_mask64) & GENMASK_ULL(INTEL_PMC_MAX_GENERIC - 1, 0);
> +			mask = hybrid(pmu, acr_cntr_mask64) & gp_mask;
>  			break;
>  		case DYN_CONSTR_ACR_CAUSE:
> -			if (hybrid(pmu, acr_cntr_mask64) == hybrid(pmu, acr_cause_mask64))
> +			if (hybrid(pmu, acr_cntr_mask64) ==
> +					hybrid(pmu, acr_cause_mask64))
>  				continue;
> -			mask = hybrid(pmu, acr_cause_mask64) & GENMASK_ULL(INTEL_PMC_MAX_GENERIC - 1, 0);
> +			mask = hybrid(pmu, acr_cause_mask64) & gp_mask;
>  			break;
>  		case DYN_CONSTR_PEBS:
> -			if (x86_pmu.arch_pebs)
> -				mask = hybrid(pmu, arch_pebs_cap).counters;
> +			if (x86_pmu.arch_pebs) {
> +				mask = hybrid(pmu, arch_pebs_cap).counters &
> +				       gp_mask;
> +			}
>  			break;
>  		case DYN_CONSTR_PDIST:
> -			if (x86_pmu.arch_pebs)
> -				mask = hybrid(pmu, arch_pebs_cap).pdists;
> +			if (x86_pmu.arch_pebs) {
> +				mask = hybrid(pmu, arch_pebs_cap).pdists &
> +				       gp_mask;
> +			}
>  			break;
>  		default:
>  			pr_warn("Unsupported dynamic constraint type %d\n", i);
> 
> base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f

Re: [RESEND Patch 1/2] perf/x86/intel: Only check GP counters for PEBS constraints validation

[Mi, Dapeng]

Hi Peter,

Could you please review and merge this change? This change suppose to be
low risky. Without this change, the dynamic constraints check would trigger
false positive on DMR/NVL. Thanks.


On 2/28/2026 1:33 PM, Dapeng Mi wrote:
> It's good enough to only check GP counters for PEBS constraints
> validation since constraints overlap can only happen on GP counters.
>
> Besides opportunistically refine the code style and use pr_warn() to
> replace pr_info() as the message itself is a warning message.
>
> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> ---
>  arch/x86/events/intel/core.c | 22 ++++++++++++++--------
>  1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index cf3a4fe06ff2..4768236c054b 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -5770,7 +5770,7 @@ static void __intel_pmu_check_dyn_constr(struct event_constraint *constr,
>  			}
>  
>  			if (check_fail) {
> -				pr_info("The two events 0x%llx and 0x%llx may not be "
> +				pr_warn("The two events 0x%llx and 0x%llx may not be "
>  					"fully scheduled under some circumstances as "
>  					"%s.\n",
>  					c1->code, c2->code, dyn_constr_type_name[type]);
> @@ -5783,6 +5783,7 @@ static void intel_pmu_check_dyn_constr(struct pmu *pmu,
>  				       struct event_constraint *constr,
>  				       u64 cntr_mask)
>  {
> +	u64 gp_mask = GENMASK_ULL(INTEL_PMC_MAX_GENERIC - 1, 0);
>  	enum dyn_constr_type i;
>  	u64 mask;
>  
> @@ -5797,20 +5798,25 @@ static void intel_pmu_check_dyn_constr(struct pmu *pmu,
>  				mask = x86_pmu.lbr_counters;
>  			break;
>  		case DYN_CONSTR_ACR_CNTR:
> -			mask = hybrid(pmu, acr_cntr_mask64) & GENMASK_ULL(INTEL_PMC_MAX_GENERIC - 1, 0);
> +			mask = hybrid(pmu, acr_cntr_mask64) & gp_mask;
>  			break;
>  		case DYN_CONSTR_ACR_CAUSE:
> -			if (hybrid(pmu, acr_cntr_mask64) == hybrid(pmu, acr_cause_mask64))
> +			if (hybrid(pmu, acr_cntr_mask64) ==
> +					hybrid(pmu, acr_cause_mask64))
>  				continue;
> -			mask = hybrid(pmu, acr_cause_mask64) & GENMASK_ULL(INTEL_PMC_MAX_GENERIC - 1, 0);
> +			mask = hybrid(pmu, acr_cause_mask64) & gp_mask;
>  			break;
>  		case DYN_CONSTR_PEBS:
> -			if (x86_pmu.arch_pebs)
> -				mask = hybrid(pmu, arch_pebs_cap).counters;
> +			if (x86_pmu.arch_pebs) {
> +				mask = hybrid(pmu, arch_pebs_cap).counters &
> +				       gp_mask;
> +			}
>  			break;
>  		case DYN_CONSTR_PDIST:
> -			if (x86_pmu.arch_pebs)
> -				mask = hybrid(pmu, arch_pebs_cap).pdists;
> +			if (x86_pmu.arch_pebs) {
> +				mask = hybrid(pmu, arch_pebs_cap).pdists &
> +				       gp_mask;
> +			}
>  			break;
>  		default:
>  			pr_warn("Unsupported dynamic constraint type %d\n", i);
>
> base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f

Re: [RESEND Patch 1/2] perf/x86/intel: Only check GP counters for PEBS constraints validation

[Peter Zijlstra]

On Thu, Mar 12, 2026 at 04:28:45PM +0800, Mi, Dapeng wrote:
> Hi Peter,
> 
> Could you please review and merge this change? This change suppose to be
> low risky. Without this change, the dynamic constraints check would trigger
> false positive on DMR/NVL. Thanks.

Ah, so I have it in queue/perf/core, it didn't have no Fixes on so I
didn't think it urgent.

Re: [RESEND Patch 1/2] perf/x86/intel: Only check GP counters for PEBS constraints validation

[Mi, Dapeng]

On 3/12/2026 4:42 PM, Peter Zijlstra wrote:
> On Thu, Mar 12, 2026 at 04:28:45PM +0800, Mi, Dapeng wrote:
>> Hi Peter,
>>
>> Could you please review and merge this change? This change suppose to be
>> low risky. Without this change, the dynamic constraints check would trigger
>> false positive on DMR/NVL. Thanks.
> Ah, so I have it in queue/perf/core, it didn't have no Fixes on so I
> didn't think it urgent.

Oh, just saw it. Thanks a lot! 😊


>