linux-kernel - Re: [RESEND PATCH 08/12] perf/x86: Extend event update interface

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] [thread-next>] [day] [month] [year] [list]

Date: Thu, 20 Jun 2024 10:38:10 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: kan.liang@...ux.intel.com
Cc: mingo@...nel.org, acme@...nel.org, namhyung@...nel.org,
	irogers@...gle.com, adrian.hunter@...el.com,
	alexander.shishkin@...ux.intel.com, linux-kernel@...r.kernel.org,
	ak@...ux.intel.com, eranian@...gle.com,
	Sandipan Das <sandipan.das@....com>,
	Ravi Bangoria <ravi.bangoria@....com>,
	silviazhao <silviazhao-oc@...oxin.com>,
	CodyYao-oc <CodyYao-oc@...oxin.com>
Subject: Re: [RESEND PATCH 08/12] perf/x86: Extend event update interface

On Tue, Jun 18, 2024 at 08:10:40AM -0700, kan.liang@...ux.intel.com wrote:
> From: Kan Liang <kan.liang@...ux.intel.com>
> 
> The current event update interface directly reads the values from the
> counter, but the values may not be the accurate ones users require. For
> example, the sample read feature wants the counter value of the member
> events when the leader event is overflow. But with the current
> implementation, the read (event update) actually happens in the NMI
> handler. There may be a small gap between the overflow and the NMI
> handler. The new Intel PEBS counters snapshotting feature can provide
> the accurate counter value in the overflow. The event update interface
> has to be updated to apply the given accurate values.
> 
> Pass the accurate values via the event update interface. If the value is
> not available, still directly read the counter.
> 
> For some cases, e.g., intel_update_topdown_event, there could be more
> than one counter/register are read. Using u64 * rather than u64 as the
> new parameter.

The stronger argument is that there is no special value to distinguish
between there begin an argument and there not being one. You cannot have
!val, because 0 might be a valid rdpmc() value.