Re: [PATCH v2 5/5] perf/arm-cmn: Support CMN S3 r2

[Robin Murphy <robin.murphy@arm.com>]

On 28/07/2026 5:57 pm, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> New issues:
> - [Medium] The virtual channel count fields (rsp_vc_num, dat_vc_num, snp_vc_num, req_vc_num) in struct arm_cmn are defined as 2-bit bitfields. The patch adds support for CMN-S3 R2, which uses 3-bit values for these counts in the hardware registers. When extracting these 3-bit values and assigning them to the 2-bit bitfields, values of 4 or higher are silently truncated. Consequently, in arm_cmn_event_attr_is_visible(), the truncated value incorrectly evaluates as < 2 (e.g., 4 truncates to 0), falsely hiding valid PMU performance events from userspace.

Anyone who has a beef with the ID register field being 3 bits when the 
relevant control register field is only 2 can take it up with the CMN 
design team. After previous lessons learned I'm choosing to leave room 
in the UAPI just in case...

> Pre-existing issues:
> - [High] In arm_cmn_discover(), the 16-bit field cmn->num_dns accumulates the number of child nodes across all XP nodes using MMIO values (CMN_CI_CHILD_COUNT). Since CMN_CI_CHILD_COUNT is a 16-bit field, accumulating multiple of these can overflow the 16-bit num_dns field. This wrapped value is used to calculate the size of the kernel heap allocation for the dn array (devm_kcalloc). During the second pass, the driver re-reads the un-wrapped hardware child counts and linearly writes to the dn array inside the loop, severely overflowing the undersized heap allocation.

But what if it was a 64-bit field and the child counts still overflowed 
that? WHAT THEN? Oh noes we are doomed! Quick we must reimplement Linux 
in multi-precision arithmetic forthwith!

Robin.