Re: [PATCH 2/2] Revert "perf: Fix the POLL_HUP delivery breakage"

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removing the synchronous `event->pmu->stop(event, 0)` re-introduces a race condition where the PMU hardware is not stopped synchronously when `event_limit` reaches 0, allowing spurious hardware interrupts to clobber the `POLL_HUP` signal.
--

commit 0345ee403573bb4c49df3d0db2209160312a4bd6
Author: Leo Yan <leo.yan@arm.com>
Revert "perf: Fix the POLL_HUP delivery breakage"

This commit reverts the addition of a synchronous PMU stop call during
event overflow when the event limit reaches zero. It relies instead on
the asynchronous irq_work scheduled by perf_event_disable_inatomic() to
disable the event, removing the direct hardware stop.

Link: https://lore.kernel.org/lkml/aICYAqM5EQUlTqtX@li-2b55cdcc-350b-11b2-a85c-a78bff51fc11.ibm.com/

> diff --git a/kernel/events/core.c b/kernel/events/core.c
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -10750,7 +10750,6 @@ static int __perf_event_overflow(struct perf_event *event,
>  		ret = 1;
>  		event->pending_kill = POLL_HUP;
>  		perf_event_disable_inatomic(event);
> -		event->pmu->stop(event, 0);

Does removing this synchronous stop introduce a race condition with
subsequent hardware interrupts?

Looking at perf_event_disable_inatomic(), it does not synchronously stop
the PMU hardware. Instead, it queues an asynchronous irq_work. Because
architecture PMU interrupt handlers generally re-enable the PMU globally
before returning from the NMI/IRQ, the counter can remain active and
overflow again before the scheduled irq_work actually executes.

If a subsequent overflow occurs, __perf_event_overflow() is re-entered
and unconditionally sets pending_kill to POLL_IN:

__perf_event_overflow() {
    ...
    event->pending_kill = POLL_IN;
    if (events && atomic_dec_and_test(&event->event_limit)) {
        ret = 1;
        event->pending_kill = POLL_HUP;
        perf_event_disable_inatomic(event);
    }
    ...
}

Since event_limit is already 0 at this point, the if condition fails, and
pending_kill remains set to POLL_IN.

When the irq_work finally runs, could this sequence cause it to deliver
POLL_IN instead of the expected POLL_HUP, silently breaking userspace
expectations?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260512-arm_cs_clean_perf_handle-v1-0-75ff373ecd22@arm.com?part=2