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>] [day] [month] [year] [list]
Message-ID: <20260206035138.1377-1-realsummitzhou@gmail.com>
Date: Fri,  6 Feb 2026 11:51:38 +0800
From: "feng.zhou" <realsummitzhou@...il.com>
To: Will Deacon <will@...nel.org>,
	Mark Rutland <mark.rutland@....com>
Cc: linux-arm-kernel@...ts.infradead.org,
	linux-perf-users@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [QUESTION] ARM DSU PMU: 32-bit counter assumption and handling of 64-bit event counters

Hi Will and Mark,

I have a question regarding the ARM DSU PMU driver implementation in
drivers/perf/arm_dsu_pmu.c, specifically about the counter width
assumptions.

Current Implementation:
======================
The driver currently assumes all event counters are 32-bit wide, with
only the cycle counter being 64-bit (lines 69-71):

/* All event counters are 32bit, with a 64bit Cycle counter */
#define DSU_PMU_COUNTER_WIDTH(idx)	\
	(((idx) == DSU_PMU_IDX_CYCLE_COUNTER) ? 64 : 32)

This assumption is used throughout the code for handling counter
overflow and calculating deltas (e.g., line 344 in dsu_pmu_event_update).

Issue Observed:
===============
I've encountered overflow issues when using perf tools on newer ARM CPUs
where the event counters appear to be 64-bit rather than 32-bit. The
current implementation causes incorrect event counting and potential data
loss due to premature overflow handling based on the 32-bit mask.

Questions:
==========
1. Is the 32-bit event counter assumption based on the ARMv8 PMU
   specification or DSU-specific hardware documentation?

2. Are there known ARM CPU implementations where DSU event counters
   exceed 32 bits? If so, how should the driver handle this variation?

3. Would it be appropriate to detect the actual counter width at runtime
   (similar to how num_counters is probed in dsu_pmu_probe_pmu), or
   should this be handled through device tree / ACPI properties?

4. Should there be a mechanism to query the hardware for the actual
   counter width to ensure compatibility with future implementations?

Thank you for your time and any insights you can provide.


Best regards,
Feng

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ