[PATCH] perf/arm-cmn: Reject unsupported hardware configurations

[Robin Murphy]

On 29/01/2026 2:23 pm, Mark Rutland wrote:
> On Thu, Jan 29, 2026 at 02:11:22PM +0000, Robin Murphy wrote:
>> So far we've been fairly lax about accepting both unknown CMN models
>> (at least with a warning), and unknown revisions of those which we
>> do know, as although things do frequently change between releases,
>> typically enough remains the same to be somewhat useful for at least
>> some basic bringup checks. However, we also make assumptions of the
>> maximum supported sizes and numbers of things in various places, and
>> there's no guarantee that something new might not be bigger and lead
>> to nasty array overflows. Make sure we only try to run on things that
>> actually match our assumptions and so will not risk memory corruption.
>>
>> Cc: stable at vger.kernel.org
>> Fixes: 7819e05a0dce ("perf/arm-cmn: Revamp model detection")
>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>> ---
>>   drivers/perf/arm-cmn.c | 13 +++++++++++++
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
>> index 2903e01f951f..24fec53ceccc 100644
>> --- a/drivers/perf/arm-cmn.c
>> +++ b/drivers/perf/arm-cmn.c
>> @@ -2422,6 +2422,15 @@ static int arm_cmn_discover(struct arm_cmn *cmn, unsigned int rgn_offset)
>>   			arm_cmn_init_node_info(cmn, reg & CMN_CHILD_NODE_ADDR, dn);
>>   			dn->portid_bits = xp->portid_bits;
>>   			dn->deviceid_bits = xp->deviceid_bits;
>> +			/*
>> +			 * Logical IDs are assigned from 0 per node type, so as
>> +			 * soon as we one bigger than expected, we can assume
>> +			 * there are more than we can cope with.
>> +			 */
>> +			if (dn->logid > CMN_MAX_NODES_PER_EVENT) {
>> +				dev_err(cmn->dev, "Invalid node number: %d\n", dn->logid);
>> +				return -ENODEV;
> 
> I think "Invalid" is ambiguous (it can read like we're saying the HW is
> wrong), and it would be better to say "Unsupported", or something to
> that effect, e.g.

Yeah, it's a bit fiddly, because "unsupported" doesn't just mean "the 
number in the driver could be bigger" either, these driver limits are 
based on the documented maximum sizes for any currently known product, i.e.:

https://developer.arm.com/documentation/107858/0203/About-CMN-S3-AE-/Configurable-options/Mesh-sizing-and-top-level-configuration

So while larger values might be "valid" for future products we don't 
know about, hardware claiming to be, say, a 16x16 CMN-650 would indeed 
arguably be "wrong".

> 	dev_err(cmn->dev, "Node number (%d) larger than supported (%d)\n",
> 		dn->logid, CMN_MAX_NODES_PER_EVENT)
> 
>> +			}
>>   
>>   			switch (dn->type) {
>>   			case CMN_TYPE_DTC:
>> @@ -2499,6 +2508,10 @@ static int arm_cmn_discover(struct arm_cmn *cmn, unsigned int rgn_offset)
>>   		cmn->mesh_x = cmn->num_xps;
>>   	cmn->mesh_y = cmn->num_xps / cmn->mesh_x;
>>   
>> +	if (max(cmn->mesh_x, cmn->mesh_y) > CMN_MAX_DIMENSION) {
>> +		dev_err(cmn->dev, "Invalid mesh size: %dx%d\n", cmn->mesh_x, cmn->mesh_y);
> 
> Likewise:
> 
> 	dev_err(cmn->dev, "Mesh size (%%dx%d) larger than supported
> 		(%d)\n", cmn->mesh_x, cmn->mesh_y, CMN_MAX_DIMENSION);
> 
>> +		return -ENODEV;
>> +	}
>>   	/* 1x1 config plays havoc with XP event encodings */
>>   	if (cmn->num_xps == 1)
>>   		dev_warn(cmn->dev, "1x1 config not fully supported, translate XP events manually\n");
> 
> ... or you could align with the wording here.

That one is different because it *is* purely a driver limitation - the 
different event encoding is known, it's just that having to have dynamic 
format attributes for the relevant event aliases would be a massive pain 
to implement, and so far nobody's asked for it. So this is just a 
reminder to the user that in this situation the "p0" aliases will 
actually encode events for port 4, "n" means port 0, etc., per the TRM:

https://developer.arm.com/documentation/101569/0300/Programmers-model/Register-descriptions/XP-register-descriptions/por-mxp-pmu-event-sel?lang=en

This is aligned with the "invalid device node type" message (other than 
capitalisation, bah!) that's been there from day 1 to fail probing on 
anything so new and unknown that it has components we can't even comprehend.

> Aside from the specific wording for the messages, this looks god to me.

Hallelujah!

Thanks,
Robin.