perf: Support Arm Bus Monitor Unit

drivers/perf/arm_cspmu/arm-bmu.c line 236

[Severity: Medium]
Should the hardware overflow state (PMOVSCLR) be cleared here when stopping the event?

If an overflow occurs right before stopping, the pending interrupt bit remains set. When arm_bmu_event_del() completes, it clears the event pointer. When the interrupt is finally delivered, wouldn't the interrupt handler see the overflow bit set and incorrectly trigger the WARN_ON for a NULL event pointer?

drivers/perf/arm_cspmu/arm-bmu.c line 288

[Severity: High]
Is the lockless compare-and-exchange logic in arm_bmu_event_read() vulnerable to the ABA problem when resetting prev_count here?

If an NMI interrupts this IRQ handler right after prev_count is set to S64_MIN but before the hardware register is written, arm_bmu_event_read() could read the old wrapped hardware value and falsely succeed in the cmpxchg because prev_count is S64_MIN.

This would save the wrapped value as prev_count. When the IRQ handler resumes and resets the hardware to S64_MIN, wouldn't subsequent delta calculations underflow and cause massive permanent counter corruption?

drivers/perf/arm_cspmu/arm-bmu.c line 343

[Severity: High]
Does this compute the PMU region offset without verifying it fits within the originally mapped memory resource size?

If the hardware provides an offset such that the new region exceeds resource_size(res), applying this unvalidated offset to the virtual base pointer and dereferencing it later will access memory outside the mapped virtual memory area, potentially causing a kernel page fault or panic.

drivers/perf/arm_cspmu/arm-bmu.c line 362

[Severity: High]
Should there be a continue statement when Non-Secure access is disabled?

Without a continue, the code proceeds to unconditionally write to BMU_PMCR and other registers for this PMU below. Writing to inaccessible secure hardware from EL1 typically triggers a Synchronous External Abort (SError), resulting in an immediate kernel panic.

drivers/perf/arm_cspmu/arm-bmu.c line 377

[Severity: High]
Are hardware interrupts left enabled if an error occurs later in the probe function?

If cpuhp_state_add_instance_nocalls() or perf_pmu_register() fails, the error path exits without clearing PMINTENCLR. If the hardware asserts the IRQ line, the kernel would receive an interrupt without a registered handler, leading to an unhandled interrupt storm.

drivers/perf/arm_cspmu/arm-bmu.c line 379

[Severity: Medium]
Is there a race in assigning the target CPU without holding the CPU hotplug read lock?

If the selected CPU goes offline before the hotplug registration, the arm_bmu_offline_cpu callback will not be invoked retroactively because cpuhp_state_add_instance_nocalls() is used below. Could this leave the PMU bound to an offline CPU, rendering it non-functional?

drivers/perf/arm_cspmu/arm-bmu.c line 391

[Severity: Medium]
Does this completely ignore -EPROBE_DEFER from platform_get_irq()?

If platform_get_irq() returns -EPROBE_DEFER, the probe simply succeeds and falls back to polling mode. This permanently breaks deferred probing for the interrupt, preventing the driver from retrying when the interrupt controller is ready.

drivers/perf/arm_cspmu/arm-bmu.c line 409

[Severity: High]
Will this cause a NULL pointer dereference if the device has no ACPI companion or if CONFIG_ACPI is disabled?

ACPI_COMPANION() returns NULL in these cases, and acpi_device_uid() directly dereferences it. This would lead to a kernel panic during driver probe on such configurations.

drivers/perf/arm_cspmu/arm-bmu.c line 414

[Severity: Low]
Is there a format string type mismatch here?

When CONFIG_PHYS_ADDR_T_64BIT is not enabled, resource_size_t is 32-bit. Passing a 32-bit integer to a %llx specifier causes undefined behavior, which can read garbage from the stack for the upper 32 bits.

drivers/perf/arm_cspmu/arm-bmu.c

[Severity: Medium]
Will an unhandled pending overflow interrupt trigger a spurious warning here?

If a performance counter overflows right before or during arm_bmu_event_del(), local interrupts are disabled by the perf core, leaving the interrupt pending. Since arm_bmu_event_del() stops the counter and sets the evcnt pointer to NULL but doesn't clear the pending overflow interrupt from the PMOVSCLR register, this pending interrupt will be processed when interrupts are re-enabled.

This leads to arm_bmu_handle_irq() executing and reading the uncleared bit from PMOVSCLR, which evaluates to true in the following WARN_ON():

[ ... ]

drivers/perf/arm_cspmu/arm-bmu.c

[Severity: High]
Does this calculation permit an out-of-bounds MMIO access if the offset from the hardware configuration register is unexpectedly large?

The off and num values are read from the MCU_CONFIG hardware register and used to calculate an offset into an ioremapped memory region that was mapped to resource_size(res). There does not appear to be a check verifying that off + num * SZ_4K does not exceed resource_size(res).

If the hardware registers provide an unexpectedly large offset, accessing memory outside the ioremapped bounds will trigger a synchronous external abort when the driver attempts to read the PMCFGR register below:

drivers/perf/arm_cspmu/arm-bmu.c

[Severity: High]
Could a CPU hotplug event during this narrow window cause a NULL pointer dereference?

The cpuhp_state_add_instance_nocalls() function is invoked before perf_pmu_register(). If the assigned CPU goes offline during this exact window, the hotplug state machine invokes arm_bmu_offline_cpu() which in turn calls arm_bmu_migrate().

This leads to perf_pmu_migrate_context() being called. Because perf_pmu_register() has not yet executed, the core context pointer is still NULL, resulting in a dereference of an invalid pointer at the start of the percpu offset region.

drivers/perf/arm_cspmu/arm-bmu.c static int arm_bmu_probe(struct platform_device *pdev) · line 411

[Severity: Low]
Does this cause a build failure in arm_bmu_probe() when CONFIG_ACPI is disabled?

Since the strict ACPI dependency was removed in Kconfig, building for standard ARM64 without ACPI is now possible. It appears acpi_device_uid() might not be stubbed out or available when CONFIG_ACPI is turned off, leading to an implicit function declaration error during compilation.