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]

Message-ID: <22c4b8dd-b4af-4a2f-ac36-61532cf726d9@linux.intel.com>
Date: Thu, 20 Jun 2024 12:18:55 -0400
From: "Liang, Kan" <kan.liang@...ux.intel.com>
To: Peter Zijlstra <peterz@...radead.org>
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 2024-06-20 4:38 a.m., Peter Zijlstra wrote:
> 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.

Indeed. I will update the description.

Thanks,
Kan