Re: [PATCH v2 4/4] perf/arm_cspmu: Make IRQ more optional

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

On 16/07/2026 4:11 pm, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
> 
> New issues:
> - [High] Unconditional swallowing of `arm_cspmu_request_irq()` error codes (such as `-EPROBE_DEFER` and `-ENOMEM`) for PMUs with >= 64-bit counters.
> 
> Pre-existing issues:
> - [High] Incorrect ordering between CPU hotplug state management and PMU registration causes Use-After-Free during teardown.
> - [High] Missing cleanup of CPU hotplug state if `platform_driver_register()` fails in module init.
> - [High] Failed `driver_attach()` in `arm_cspmu_impl_register()` leaves dangling pointers in the `impl_match` array.
> - [High] Stack-allocated bitmap cast to `u32 *` leaves memory uninitialized on Big Endian systems, causing reads of uninitialized stack memory.
> --
> 
> --- Patch [4]: [PATCH v2 4/4] perf/arm_cspmu: Make IRQ more optional ---
> commit e7afdbca83ffd562889abdf4a15a47f1af9fc395
> Author: Robin Murphy <robin.murphy@arm.com>
> 
> perf/arm_cspmu: Make IRQ more optional
> 
> This commit allows the driver to continue probing even if it fails to
> request an IRQ, provided the PMU has 64-bit counters. It assumes that
> 64-bit counters will not overflow in a realistic timeframe.
> 
>> diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
>> index 385d3e34694f2..007038aa7e9a6 100644
>> --- a/drivers/perf/arm_cspmu/arm_cspmu.c
>> +++ b/drivers/perf/arm_cspmu/arm_cspmu.c
>> @@ -1256,8 +1256,11 @@ static int arm_cspmu_device_probe(struct platform_device *pdev)
>>   		return ret;
>>   
>>   	ret = arm_cspmu_request_irq(cspmu);
>> -	if (ret)
>> -		return ret;
>> +	if (ret) {
>> +		if (counter_size(cspmu) < 64)
>> +			return ret;
> 
> [Severity: High]
> Does this unintentionally swallow error codes like -EPROBE_DEFER or
> -ENOMEM for 64-bit PMUs?

No. It does that *intentionally* - this is literally the entire point of 
the patch. If there is an IRQ and we can claim it for the sake of 
correctness then fine, but since in practice we'll never use it, there 
is no point worrying about any error, including a missing interrupt 
controller driver that might otherwise defer forever.

Robin.