linux-kernel - Re: [Patch v2 10/24] perf/x86/intel: Process arch-PEBS records or record fragments

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <98112b48-5ca6-4077-a842-83d1407f1860@linux.intel.com>
Date: Wed, 26 Feb 2025 10:45:11 -0500
From: "Liang, Kan" <kan.liang@...ux.intel.com>
To: Peter Zijlstra <peterz@...radead.org>,
 "Mi, Dapeng" <dapeng1.mi@...ux.intel.com>
Cc: Ingo Molnar <mingo@...hat.com>, Arnaldo Carvalho de Melo
 <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
 Ian Rogers <irogers@...gle.com>, Adrian Hunter <adrian.hunter@...el.com>,
 Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
 Andi Kleen <ak@...ux.intel.com>, Eranian Stephane <eranian@...gle.com>,
 linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
 Dapeng Mi <dapeng1.mi@...el.com>
Subject: Re: [Patch v2 10/24] perf/x86/intel: Process arch-PEBS records or
 record fragments



On 2025-02-26 4:35 a.m., Peter Zijlstra wrote:
> On Wed, Feb 26, 2025 at 01:20:37PM +0800, Mi, Dapeng wrote:
> 
>>> Also, should that workaround have been extended to also include
>>> GLOBAL_STATUS_PERF_METRICS_OVF in that mask, or was that defect fixed
>>> for every chip capable of metrics stuff?
>>
>> hmm,  per my understanding, GLOBAL_STATUS_PERF_METRICS_OVF handling should
>> only be skipped when fixed counter 3 or perf metrics are included in PEBS
>> counter group. In this case, the slots and topdown metrics have been
>> updated by PEBS handler. It should not be processed again.
>>
>> @Kan Liang, is it correct?
> 
> Right, so the thing is, *any* PEBS event pending will clear METRICS_OVF
> per:
> 
>                 status &= x86_pmu.intel_ctrl | GLOBAL_STATUS_TRACE_TOPAPMI;
> 

Yes, we have to add it for both legacy PEBS and ARCH PEBS.

An alternative way may change the order of handling the overflow bit.

The commit daa864b8f8e3 ("perf/x86/pebs: Fix handling of PEBS buffer
overflows") has moved the "status &= ~cpuc->pebs_enabled;" out of PEBS
overflow code.

As long as the PEBS overflow is handled after PT, I don't think the
above is required anymore.

It should be similar to METRICS_OVF. But the PEBS counters snapshotting
should be specially handled, since the PEBS will handle the metrics
counter as well.

@@ -3211,7 +3211,8 @@ static int handle_pmi_common(struct pt_regs *regs,
u64 status)
 	/*
 	 * Intel Perf metrics
 	 */
-	if (__test_and_clear_bit(GLOBAL_STATUS_PERF_METRICS_OVF_BIT, (unsigned
long *)&status)) {
+	if (__test_and_clear_bit(GLOBAL_STATUS_PERF_METRICS_OVF_BIT, (unsigned
long *)&status) &&
+	
!is_pebs_counter_event_group(cpuc->events[INTEL_PMC_IDX_FIXED_SLOTS])) {
 		handled++;
 		static_call(intel_pmu_update_topdown_event)(NULL, NULL);
 	}


Thanks,
Kan